Notes on Yum Changes

[seth vidal]

> 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.

The problem was with xorg in RAWHIDE. Not in a normal repository. If
people want to run rawhide then they can figure out some subset of
pkging problems that come up.

I added the obsoletes option to yum.conf so that people who feel
confident in obsoletes. I do not feel comfortable making obsoletes the
default. The last time there was a circular obsoletes in the core distro
was b/t zebra and routed. They each obsoleted each other.

I discovered the problem b/c I watched a system oscillate b/t the two
packages every other day.

What I'm asking for is how should yum track that? Do you want it to
maintain some state of what packages used to be installed outside of the
rpmdb? Should I create a secondary yumdb of obsoletes so I can know what
one was installed before the first obsoletes?


> There's nothing about solving conflicts. Just not letting a conflict on
> some packages affect the other unrelated (ie, those that do not depend
> on them).

We're not talking about conflicts  - we're talking about obsoletes.

> 
> > In case of your above example, how should yum know it needs to skip the
> > package that holds the obsoletes, and not the package for which a
> > security update is released?
> 
> 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.
>    if, since there was a problem with some packages, it offered to
> install the other unrelated ones, the problem would be minimized and
> life would be made easier for the end user.

So you would like yum, in the event of an automated loop to print out an
error message but to do everything else in the transaction? This seems
like safe behavior to you?

> Imagine there was a bug with mount (which is suid root).
> An update for util-linux wouldn't be upgraded on one of the last update
> batches because some xorg-x11 packages obsoleted others, halting the
> process.

What about the inverse case?

yum can update trivial things but b/c of some issue can't update a
security related patch. Oh but wait, we have no metadata to tell us that
one patch is security and one isn't so we can't rank the updates.

The reason I error out on any package failing is to try to get the
attention of the user. Happily continuing will typically make the user
ignore it when they should probably be paying closer attention.


> 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".

Where did I say either of those? I've asked, repeatedly, for the process
everyone agrees on as the best behavior in those situations and I've
gotten a general 'solve loops' response. No one has said:

Answer these questions:

In the event of a conflict what should occur? 
In the event of a conflict with a -y specified?
In the event of an unresolvable dep?
In the event of an unresolvable dept with -y specified?
In the event of an obsoleting loop?
In the event of an obsoleting loop with -y specified?

If I'm going to write code that handles these cases I would love to get
some other people's input on the best way to handle it.


> 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.

Where are the arrogant statements? I'm GENUINELY looking for expected
behavior.




> > > > you write up the process for what has to occur and get EVERYONE to agree
> > > > on it and I'll write the code.
> > > In a very highlevel way, I already did, wouldn't you say so?
> > 
> > No. You might have indicated a problem that you perceive,
> 
> 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.
> 
> And the excuse for not solving is not "limited time" (which I would
> understand) but "WONTFIX" (not how the replies were written, but how
> they "sounded" to my "ears").

Then get your ears checked. That's not what I've been saying. But I'll
be damned if I'm going to "fix" something which will make it equally bad
as if I hadn't.

> 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?

It's not about breaking loops. It's about expected behavior for pkging
conflicts or problems of various types. It's about handling automated
runs.

-sv