Notes on Yum Changes

Leonard den Ottolander leonard at den.ottolander.nl
Tue Sep 7 13:40:41 UTC 2004


Hi Rui,

On Tue, 2004-09-07 at 14:32, Rui Miguel Seabra wrote:
> I never mentioned hiding, nor was that the intention.

So how would you make such a failure stand out in an otherwise
successful update? Example: Critical update was skipped because a
dependency issue. Newbie: "Oh, it's just a warning as the program
completed successfully." This is not more or less valid than the
examples you give.

> What multiple repos? Why do you suppose there have to be multiple repos
> for this to happen?
> 
> The latest problem of barfing due to obsolete packages happened recently
> with xorg.

You are correct that I make a bit of an assumption, but in stable
distribution trees such conflicts should be seldom and if they do exist
it's fine newbies start crying for help as there is obviously something
wrong with the tree.

> Huh? You're not understanding:
>    yum barfed because of obsolete packages.
>    if there was an unrelated security package, it wouldn't be applied
> because yum barfed.

Indeed the packages are unrelated. But... 

> As you can see, there is no X here:
> [rms at roque ~]$ rpm -q util-linux --requires

That might be so, but what makes you so sure hiding the xorg-x11
packages won't cause other updates to fail in the process?

> I'm not demaning it to be solved, I wondered why something wsn't the
> default and I don't see any answer with a sensible reason. Just
> "NOTABUG" or "WONTFIX".

"Not a bug" is quite different from "won't fix".

> All I read were excuses. I can understand limited time, not bad and
> arrogant statements, like expecting a newbie to be able to solve yum
> dependency problems.

The dependency problems are not in yum but in the tree(s).

> > > > you write up the process for what has to occur and get EVERYONE to agree

> Not perceive. Exists. A newbie user is placed with a "difficult"
> challenge unecessarily, and important packages may not be upgraded due
> to certain bugs in unrelated packages.

Ok. But you perceive this to be a yum issue instead of a repo issue. And
you still don't answer the essential part, namely give us a definition
of how yum should behave in case of conflicts. Just skipping packages
might cause unexpected side effects.

> >  but you have
> > neither described a standard on how to handle it, nor have you got
> > everyone to agree on your solution.
> 
> I don't need to describe in detail what's taught on classes about
> finding paths on mazes without getting lost on loops, do I?

Cute. If it's so obvious to you you might want to come up with a patch
so we can evaluate it. But iirc your first proposal was just to toggle a
switch, which doesn't cut it.

> You mark where you have been, so that if you find it again, you know
> you've been there.
> You mark obsolete "paths" until you find one that's already registered
> (a loop).

How would the entry point in that path (assuming a circular obsoletes
situation) influence which package gets installed or removed?

> Anyway, I'm not complaining my self. I just think this is a bad thing
> for newbie users. For me? It's just a minute (or so) more.

As pointed out these issues will hardly exist in single distribution
repositories (they shouldn't).

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research






More information about the fedora-devel-list mailing list