Notes on Yum Changes

Rui Miguel Seabra rms at 1407.org
Tue Sep 7 14:17:56 UTC 2004


On Tue, 2004-09-07 at 09:09 -0400, seth vidal wrote:
> > 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.

And I did figure.
But this is nothing that couldn't happen by accident on the stable tree.

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

Nothing so complicated. At each run one could keep a small graph of the
obsoletes, and test wether one is walking _again_ through some path.

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

Ok, the pratical effects ends up being the same, I understand what you
mean by the difference. I was using the more general meaning of
conflict.

There's nothing about solving obsoletes. Just not letting an obsolete on
some package affect other unrelated packages (ie, those that do not
depend on them).

Is it clearer like this? Sorry for the terminology inadequacy...

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

If the other packages are unrelated (no dependency link), yes.

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

It's not even a matter of rank, the rank here was only to highlight what
I mean: unrelated packages should be safe to work on even if there's an
obsolete conflict somewhere else.

One can track obsoletes in order to avoid loops, is there a graph
library for python? I suppose so, but I'm not familiar with python,
sorry.

> 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 understand that, and that works fine on people who have bigger
experience with packages. I used to do this stuff "by hand", so I'm very
glad there's software like yum (which since 2.1 satisfies my "needs"
much more than it did before) and apt that help me on that.

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

Ok, I'm probably drawning meanings from interpretation, but I haven't
generally said solve loop. I've said that one should keep a log of loops
(and obsoletes loops) and when one is found see if anything can be done
with the rest before failing.
 
> Answer these questions:

I'll answer considering the following terminology, please correct me
where I get it wrong:
  conflict -> like two packages trying to own the same file
  unresolvable dep -> self explanatory
  obsolete loop -> self explanatory

> In the event of a conflict what should occur? 
  I think that those packages and those that depend on them should be
skipped, and try to work on with the rest.

> In the event of a conflict with a -y specified?
  Should there even exist such a question to answer y? Assuming it
should...
  ... and considering the above terminology, I think it shouldn't work.
-y is a way to force an answer because you expect everything to be ok,
but in this case not only it isn't, it can have serious consequences.
  But IMHO that question shouldn't exist.

> In the event of an unresolvable dep?
> In the event of an unresolvable dept with -y specified?
  ditto for both

> In the event of an obsoleting loop?
> In the event of an obsoleting loop with -y specified?
  ditto for both

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

I think that if some packages don't depend on the problematic packages,
the metapackager should try to see if he can work with them.

The only problem that could happen is very misbehaved packages (like,
not telling the truth about what they require).

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

Not you specifically. I'm sorry if I haven't been specific enough to
describe the expected behaviour, I didn't have in mind what kind of
description you wanted. I hope my answers to your questions were
helpful.

> Then get your ears checked. That's not what I've been saying.

I think I wrongly assumed some people were in the AUTHORS file.
My mistake.

>  But I'll
> be damned if I'm going to "fix" something which will make it equally bad
> as if I hadn't.

I understand. But consider this:
 Yum is much, much better now. Consider me as someone who up until
recently _really_ preferred apt to yum, now they're pratically the same,
as far as I need a meta packager.

 Since obviously apt is the preferred metapackager by FC maintainers at
the moment, I think the current minor differences are completely
irrelevant, and not being familiar with python it's better to suggest
how to solve the problems instead of just working around them.

 So I'm a convert :) I'm just trying to incite yum into an even better
spot.

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

I really hope my answers help.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040907/d4d6d73f/attachment.sig>


More information about the fedora-devel-list mailing list