Red Hat Bugzilla – Bug 68410
pkgorder doesn't put packages in order to minimize cd usage
Last modified: 2007-03-26 23:54:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020515
Description of problem:
PYTHONPATH=/usr/lib/anaconda pkgorder i386/ i386 > pkgfile
gives a list of packages, but I don't think that it is doing well at putting
them in a proper order. spamassassin (line 772) and xmms-skins (which no
package depends on, and which is not in the comps file except in the dependency
part) comes before evolution, ypbind, gedit, nautilus, etc. These should all
come before packages such as xmms-skins that are not in the installation section
of the comps file.
This is possibly similar to Bug #64995, in which pkgorder should have put all
packages from the entire comps file on the first two discs.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.PYTHONPATH=/usr/lib/anaconda pkgorder i386/ i386 > pkgfile
Actual Results: I get the pkgfile for Limbo, where disc2 ends with pine and
postfix (line 1150), and disc3 starts with gimp and glut. Several files seem to
come sooner than they should.
Expected Results: Choosing all selections in a Custom install (except for
'Everything') should only use two discs (or close thereto).
There were some dependency loops present in the limbo tree, I've added whiteout
appropriately since then.
Can I have a copy of the comps.xml file or a patch?
Please confirm this is working better with the second public beta. Thanks.
No, it is not working better. dtach, doxygen-doxywizard and efax (to name a
few) are on the second CD, yet they are not in the top part of the comps file.
xcdroast, zebra, radvd, pine, statserial, etc., are in the top part of the comps
file, but are on disc3.
Changing summary field as it is *a* correct order. Unfortunately, one of the
problems with partial orderings of sets is that there is no one true correct order.
It is an order, but I would not call it correct. Why even try to split the
packages in any kind of order? I think that you would make the order such that
the most used packages would be on the first two discs if possible. Everything
in the top section of the comps file show fit on two discs (or close thereto. I
haven't had a chance to figure out if they would all fit on the two discs,
because I haven't found a comps.xml file that would do the right thing). The
extra disc could be more like the old powertools disc--you don't need it for a
regular install, but it would install the packages if you did an Everything
Orderings are dictated solely by package requires and prereqs implying
successors and predecessors for certain packages. Beyond that, *any* order is
correct. The problem is that I don't want to have to be determining that order
myself -- we just use the ordering of the transaction set as decided by rpm. So
the ordering we get is perfectly valid, it's just not one which matches your
idea of "optimum". Jeff's idea of an "optimum" order is the one where all
packages with successors are first and then all packages without successors come
afterwards; this is even more interesting for handling CD splits in some sort of
And FWIW, you could never use the Powertools disc in the install, which is part
of why it was canned.
We'll address this in a future release.
Just checking the status...was anything changed in Phoebe?
I have been looking at pkgorder in Shrike, and I see that there have been a few
changes. I tried putting the groups that I want to install in the complist, but
I still get some of the packages that I want on disc 3.
I still don't understand why packages like kde2-compat get ordered before
kdebase, kdelibs, etc. kde2-compat isn't in the first half of the comps.xml
file whereas kdebase et al. is!
Setting up the PKGORDER_DEBUG env variable helps me see what it going on, but I
still cannot get the comps in the order that I like. Any ideas about how to
make pkgorder order the packages more efficiently vis a vis CD usage?
Current CVS acts in a way that's probably more consistent with what you were
looking for by running multiple transaction sets and ordering them each
I was just going to add a patch to do just that. Thanks for the update.