[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rpm groups and fedora: a modest proposal

On Tue, 25 May 2004 21:20:51 -0400, Brad Smith <brads redhat com> wrote:
> If so, what about packages that don't appear in comps.xml? Let's face
> it, a lot of people are going to install packages from the third-party
> repos and it would be awkward at best to just have them all lumped into
> an "Other" category.

Once repos start producing their own comps.xml files, and the
management tools understand you to handle repo specific comps.xml
files...there is no all encompassing "Other" category.
> Plus I have a personal interest in doing the opposite of what you're
> suggesting. Currently the headers stored on apt and yum servers don't
> include the Group field though it would be great for people to be able
> to search by in Fedora Tracker. Thus I'm very pleased that the new XML
> metadata format does include this information.

Only if the group field is useful...which it isnt, if yer suppose to
stick with the canonical groupnames as mentioned in the parent post.
Some yum mirrors understand yum's group commands that work of of
comps.xml file definitions. Hell even if you are using a Fedora Core
mirror with yum that doesnt support yum's group features you can steal
the comps.xml file and stick it in yer yum cache and get the group
functionality back.  Hell...you can even imagine having people create
personalized comps.xml files for use with yum that regroup the same
repository to better suit their needs. There is no reason that each
repo can not define their own comps.xml groupings to be useful both as
a way to group categories in a way that makes intuitive sense for that
repository and to use as a metapackage installation method.  Usage of
comps.xml files at all repositories makes sense, if there is any
desire to make it possible for people to use 3rd party media sets at
install time (at some point in the future) or when
system-config-packages gets rebaked to include support for repos.
Relying on the somewhat static and inflexible Group tag that rpm knows
about is revisionist history at this point. The base distro tools have
moved very far away from that and rely heavily on comps information
now. Instead of moving back in time, we need to move forward and make
usage of the comps file MORE pervasive and build tools to help repos
build and maintainer their own comps files that provide the grouping
information to the distro tools that understand grouping.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]