Red Hat Bugzilla – Bug 216866
RFE: Pirut "List" tab: enabling more information
Last modified: 2007-11-30 17:11:49 EST
Description of proposed enhancement:
Currently, the "list" tab in pirut merely constructs a PirutPackageList object
(as is used with the "search" tab). This is effective, but can result in a VERY
long and unwieldy list of packages, and it can be hard to distinguish between
different types, or groups, of RPMs using this list.
That said, using the "browse" tab (making use of comps.xml) does *not* show all
available packages - while this is perfect for less experienced users, the
"list" tab seems to be more suited for a more experienced crowd, especially when
the system is subscribed to 3rd-party repositories.
One method around this "unmanaged" list issue is making use of RPM's built-in
"groups" tag... I know that comps.xml goes a long way to effectively "replacing"
this tag, but given the nature of the "list" tab (along with the description
above), comps.xml is simply not adequate for all needs. Using a combination of
the two would be more efficient. I therefore propose to add RPM Groups-based
filtering on the "list" tab's contents, as well as adding a "description" box
for the "list" tab.
I manage a local mirror of several (mixed) repositories for our Fedora
installations, and have opted to modify pirut to include RPM group information.
(see the attached patch for pirut-1.2.8). This patch is by no means the
"ultimate/final" solution, just a start. Is it possible to implement this or
something similar in the upstream pirut? I'm willing to assist further if
As a side effect (requested by some of our users), the patch also allows enables
pirut users to browse the packages while offline (using yum's cache).
Created attachment 141903 [details]
patch for pirut-1.2.8: enables RPM group information, and offline browsing
The groups tag is very intentionally not used -- realistically, it's likely to
stop being populated at all. Further improvements to comps are something that
could be discussed (preferably on yum-devel) to make things scale more but I
don't think that overloading the list view is the way to do this