Bug 68410 - pkgorder doesn't put packages in order to minimize cd usage
pkgorder doesn't put packages in order to minimize cd usage
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
9
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks: 67217
  Show dependency treegraph
 
Reported: 2002-07-09 19:26 EDT by Forrest
Modified: 2007-03-26 23:54 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-29 16:36:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Forrest 2002-07-09 19:26:45 EDT
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).
Comment 1 Jeremy Katz 2002-07-09 19:51:25 EDT
There were some dependency loops present in the limbo tree, I've added whiteout
appropriately since then.
Comment 2 Forrest 2002-07-10 22:48:28 EDT
Can I have a copy of the comps.xml file or a patch?
Comment 3 Jay Turner 2002-07-29 16:30:24 EDT
Please confirm this is working better with the second public beta.  Thanks.
Comment 4 Forrest 2002-07-31 15:42:42 EDT
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.
Comment 5 Jeremy Katz 2002-08-07 19:24:10 EDT
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.
Comment 6 Forrest 2002-08-09 20:38:36 EDT
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.
Comment 7 Jeremy Katz 2002-08-09 23:31:52 EDT
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.
Comment 8 Michael Fulbright 2002-08-14 12:11:19 EDT
We'll address this in a future release.
Comment 9 Forrest 2002-12-26 18:48:12 EST
Just checking the status...was anything changed in Phoebe?
Comment 10 Forrest 2003-04-28 19:56:30 EDT
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?
Comment 11 Jeremy Katz 2003-06-29 16:36:15 EDT
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.
Comment 12 Forrest 2003-06-30 19:44:42 EDT
I was just going to add a patch to do just that.  Thanks for the update.

Note You need to log in before you can comment on or make changes to this bug.