Bug 89137 - feature requests for redhat-config-packages
Summary: feature requests for redhat-config-packages
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-packages
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-18 05:27 UTC by greg hosler
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2005-09-21 20:21:00 UTC

Attachments (Terms of Use)

Description greg hosler 2003-04-18 05:27:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Summary of missing functionality in redhat-config-packages (some of these items
are bugzilled separately by other people)

- config-packages does not support management of packages that are not in the
comps file used by anaconda. in particular, packages that are not listed within
the anaconda groups, but ARE part of Red Hat Linux (there are actually an awful
lot of these type of packages), are NOT installable with redhat-config-packages.
redhat-config-packages ought to be aware of every single package that ships w/
RHL _by default_. 

- Additionally, you should be able to point redhat-config-packages to additional
directories that it should include in its package listing (and if there is a
comps file there, or equivalent, it might also make use of that to display
pretty groups). failing a comps file, should be an attempt made to group
packages with teh same name (but different version number) in the same place
that the RHL distribution package is listed (e.g. a directory of eratta rpms
should OPTIONALLY appear as merged throughout the distribution supplied rpm groups).

- All installed rpms should be listed, including non RHL rpms, and the user
should have the option of uninstalling them.

- When an rpm (or set of rpms) is selected for uninstallation, (or
installation), dependency checks are done, and that is good. What is bad is that
if a dependcy check fail, then the failure is listed, and NOT the required
package. as an example, a few days ago I ran redhat-config-packages, made a
bunch of changes to my package selection, and received messages such as
"milkmod.so.0 required" or equivalent. I believe that I had red-rpmdb installed,
and it is my understanding that with rpmdb installed, rpm is supposed to tell me
WHICH PACKAGE is the dependency package. This would be most useful to a new user
who might not be able to associate particular library files to particular rpms.
Since redhat-config-packages has the ui and package listing within the UI at
it's disposal, and dependencies ought to be translated into rpms, and then
dependent rpms ought to be looked 
up in the UI, and the user should be told (for example):

      admin-tools:<pkg name> requires development-tools:<pkg name>

(using appropriate groups, of course)

- redhat-config-packages limits itself to the RHL cdroms - it should support a
config option to point at the directory that contains the iso images. Ideally,
specs should be published, so that 3rd parties, or end-users, might be able to
create directories/cdroms/comps files/whatever that would allow user created /
3rd-part supplied packages to be integrated into the package listing.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. see above

Additional info:

I'm filing this as a RFE, as most is proposed new functionality. Having said
that, most of these fixes are necessary in order to make redhat-config-packages
a really good package manager.

Comment 1 Jeremy Katz 2003-05-05 16:36:53 UTC
Brent is looking at doing some of this

Comment 2 David Wagoner 2003-11-14 02:50:28 UTC
these ideas sound really good and I agree. i currently use synaptic
because the redhat package configurator does not give me the ability
to do everything i want to.

Comment 3 Jeremy Katz 2005-09-21 20:21:00 UTC
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.

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