[Yum] Re: upgrade and update

Axel Thimm Axel.Thimm at physik.fu-berlin.de
Thu Oct 9 19:04:37 UTC 2003


On Thu, Oct 09, 2003 at 01:41:23PM -0400, seth vidal wrote:
> > Obsolete graphs break down into several continouus and small
> > subgraphs, with most packages living on one-node graphs.
> > 
> > In order to find the non-trivial graphs one can start with the
> > packages that do contain "Obsoletes:" (These are 345 out of 1892
> > packages on a RH9 system with lots of additional repos included,
> > e.g. about 1/6th of the total packages ensemble). Then traverse down
> > the Obsoletes tree to the leaf node for each such package testing
> > whether any new Obsolete: obsoletes the staring package.
> 
> And when you're dealing with 4000 packages across 10 repositories?

You mean twice as big as the example above? I would not see a problem
in scaling that soon, and the problem is linear in the number of
packages.

The below sketched algorithm is a cheap one-pass loop over the
packages.

> > Even better: A policy to deal with obsoletes when "upgrading" would be
> > to ignore all packages that are being obsoleted by others.
> 
> This is what yum update does now. obsoletes are not considered in the
> loop - only updates.
> 
> installed:
> foo 0:1.1-1
> 
> available:
> foo 0:1.1-2
> bar 0:1.0-1 (obsoletes foo)
> 
> a yum update will update from foo 0:1.1-1 to 0:1.1-2
> a yum upgrade should obsolete foo with bar 0:1.0-1

That is not what I wrote above (note the passive in "being
obsoleted"): The described obsolete-policy would have removed foo from
the pool of possible updates, so it is definitely not what yum update
does now.

> > A two, three or larger loop would automatically be removed that
> > way resulting in a consistent package pool to opertae with. So in
> > the above scheme while traversing the obsoletes tree yum could
> > remove the packages from its internal ensemble.
> > 
> > Does that make sense?
> 
> no.
> Do you understand what the problem is with obsoleting by default?

I wasn't suggesting here anything about defining default behaviour
(that's was a different reply ;), but a way to drop obsolete-loops
when it comes to deal with them.

> Something I've considered doing is having obsoletes automatically
> considered and simply tell the users that they have packages installed
> that are being obsoleted by an available package. so when you run a yum
> update - it looks through and says - "oh, look at that, you've got a
> package installed (foo) that is due to be obsoleted (bar), you should
> think  about that."

Very nice idea, maybe even segment off "pure upgrades", "additional
packages pulled in", "obsoleted packages by ...".

> The other problem I have with obsoletes by default is the possibility
> for two packages to obsolete the same package. Which one wins?
> 
> foo is installed
> bar obsoletes foo
> baz obsoletes foo
> 
> Do you install them both? That seems wrong somehow.

In the scheme described above? None, as they will have both been
removed from the set of possible updates. That's the only way to
remove obsolete loops, if you don't have any other preference handle
(scoring etc.).

Should you consider the above "drop-obsolete-loops" algorithm, it
would be nice to have this displayed as well to the user, e.g.

"The following set of packages are creating obsoletes-loops, please
choose one and install with yum install:

       zebra - gated
       foo - bar - baz
"

Identifying the loops (for the output) is not as cheap as simply
removing them, but is still affordable.
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.baseurl.org/pipermail/yum/attachments/20031009/fd7b87ad/attachment-0001.pgp 


More information about the Yum mailing list