Bug 143571

Summary: RFE: Add resolving of dependencies via yum / integrate with up2date
Product: [Fedora] Fedora Reporter: David Anderson <david>
Component: system-config-packagesAssignee: Jeremy Katz <katzj>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mattdm
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-21 19:54:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Anderson 2004-12-22 15:07:44 UTC
From Bugzilla Helper: 
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3) (KHTML, like 
Gecko) 
 
Description of problem: 
Dependency nightmares - we all know what we're talking about! (My 
most recent was with scribus - it took me _ages_ to track down a 
suitable littlecms RPM...). 
 
Thankfully, yum (or apt, if you prefer) have solved this problem for 
people comfortable with the command line (or with obtaining 3rd-party 
graphical package managers, e.g. gyum). 
 
Unfortunately, a pure installation of Fedora cannot yet handle 
dependencies at the desktop/GUI level. If you download an RPM, and 
click on it to install, then you'll get a fatal error if it has 
non-installed dependencies. 
 
Suggested resolution: Add yum capability to system-config-packages 
(in its system-install-packages guise). The most obvious way to do 
this would be to integrate system-config-packages with up2date, (or 
at least share some common code) because up2date already handles 
dependencies and yum, and it would be silly to have two separate 
configuration files. Also, if they share the same configuration file 
then problems won't arise where dependencies are only obtainable in a 
repository that is only set up in one of the tools. 
If one of the RPM-handling tools handles dependencies and yum, it's 
inconsistent and confusing if the other doesn't. 
 
Then, if the default configuration file had Fedora Extras in it too 
(should that exist yet!), then it might be able to resolve just about 
anything vaguely reasonable (livna stuff excepted). Non-command-line 
users would be much relieved, and it would save some time for the 
rest of us too. 
Whilst system-install-packages asks for distribution CDs, this can 
fail if there have been updates released or installed, because these 
aren't on the CDs. 
 
Obviously this will only work if a net connection is available. If 
system-install-packages can't satisfy dependencies from its magic 
knowledge of the distribution CDs, and if it tries to contact remote 
repos and fails, it should pop up a box with a suitable message and 
option to try again. 
 
Version-Release number of selected component (if applicable): 
1.2.12-1 
 
How reproducible: 
Always 
 
Steps to Reproduce: 
1. Download RPM of some cool new software. 
2. Click to install 
 
     
 
Actual Results:  Irritation at missing dependencies and work needed 
to go find them, somewhere. 
 
Expected Results:  Marvel at the coolness of system-install-packages 
as it downloads and installs needed dependencies. It just works!

Comment 1 Sean Middleditch 2005-01-19 00:24:53 UTC
An additional complication occurs when the RPM you grab has
non-standard dependencies.  In many cases the site you got the RPM
from includes packages of the dependencies.  (For example, grabbing a
Gossip RPM probably needs a Loudmouth RPM, which needs GNU-TLS and so on.)

If a RPM could include an additional header/key specifying the
site/vendor it came from and a repository for that site then the
installer could temporarily add that repository during dependency
resolution.  This would allow a vendor to put an RPM on their site and
a private repository of dependencies, and the user can just click
Install Package (a link to the main RPM) and have it and its
dependencies installed.

Any temporary repositories should probably default to requiring GPG
key signing and verifying and require that all packages from the
repository be signed by the same key as the package that linked to the
repository.

Comment 2 Matthew Miller 2005-04-26 15:55:14 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 3 Matthew Miller 2005-05-25 03:35:20 UTC
This RFE seems pretty well-phrased. Moving from FC2 to devel.

Comment 4 Jeremy Katz 2005-09-21 19:54:19 UTC
The next generation tool will handle this much better