Red Hat Bugzilla – Bug 107104
r-c-p installs packages even though deps are not yet met
Last modified: 2007-11-30 17:10:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031013
Description of problem:
I double-clicked on the spamassassin RPM for FC test3, and
redhat-install-packages launched, as expected. I then hit "continue" on the
dialog it brought up, and then it started the progress bar. First it installed
spamassassin, but then it came up and asked me for one of the FC test3 CDs. Not
having them, I hit "Cancel", expecting that nothing would be done -- not so.
Spamassassin was installed, but without its dependencies (in this case, a bunch
of perl deps that don't come in FC test3's default package set). I hope this is
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to install spamassasin using redhat-install-packages, by double-clicking
on the RPM from Nautilus
2. When r-i-p asks for one of the FC test3 discs, hit the "Cancel" button
At that point, the spamassassin package has already been installed (r-c-p
doesn't copy all the packages to the hard disk and then install them, doing so
is a waste of hard drive space and slows things down significantly), so if you
cancel, yes, you'll be left with broken deps.
Will think about what to do about this in the future.
This remains the same on Fedora Core 1.
It would appear that the order in which the RPMs are installed is not
the order that would satisfy the dependencies, i.e. if package-A
requires package-B then package-B should be installed first.
If I change line 224 of /usr/share/redhat-config-packages/GroupSet.py from
pkgnevra = depMatch(name, evr, flags, self.grpset.hdrlist)
pkgnevra = ""
A dialog box is displayed to say that dependencies could not be resolved.
A quick fix to this would be to allow a command-line flag to specify
if dependecies should be left unresolved, i.e. not via the install CD
This report is filed against a product which is no longer supported. It is very
likely that the problem is resolved in the current version of Fedora Core or
scheduled to be resolved with the new system-config-packages scheduled to land
in Fedora Core 5.