From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020515 Description of problem: Running: 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): How reproducible: Always 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 installation.
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 "optimal" manner 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 independently.
I was just going to add a patch to do just that. Thanks for the update.