Package updating

seth vidal skvidal at linux.duke.edu
Sun Dec 18 09:55:10 UTC 2005


> But this (as the scripts on the page) f.ex. today upgraded cpp (which pulls
> in a lot of gcc-related stuff), and then tries to upgrade those too, one by
> one.  Ideally, after installing something it should cut down the list of
> stuff to install, and if something can't be upgraded don't try the stuff
> depending on it.


so if there is a cascade of dependencies (a deps b deps c deps d deps e
deps f) you're going to pull in most of the packages anyway.

What if I told you there was the information in yum's transaction set
about those dependencies and that after the initial transaction set was
determined you could, if you wanted, break the transaction set up based
on those deps into discrete groups of transactions to run?

You could - it would mean writing a fair bit of code to:
 1. get that information from the ts and figure out where the dep
boundaries are
 2. store the information on the full set of packages for the total
transaction and store where the sub-transaction boundaries exist
 3. attempt to depsolve and run each sub-transaction group of packages
and record failures/unresolved deps, etc.


it's not insurmountable but it's definitely possible.

Essentially you could do it in one of two places:
1.  do it if there is an unresolvable dependency failure.
2.  do it if the transaction set is greater than N packages. Breaking
apart large transaction is something we've wanted to do for quite a
while it just takes time and some focused thinking to do it correctly.

wanna try?

-sv





More information about the test mailing list