rpm groups and fedora: a modest proposal

Nicolas Mailhot Nicolas.Mailhot at laPoste.net
Wed May 26 09:02:36 UTC 2004


Le mar, 25/05/2004 à 23:22 -0700, David Kewley a écrit :
> Brad Smith wrote on Tuesday 25 May 2004 18:49:
> > I concede the point about utils like anaconda being geared more toward
> > using comps.xml than the Group field and agree that we should settle on
> > one rather than both. But I'm not convinced that it's better to keep all
> > this information in one file (even one file per repo) instead of in the
> > packages themselves. What, other than current development trends,
> > warrants the use of a file that would need to be updated every time a
> > package got added to a repository if reaching an accepted standard for
> > Group field values would suffice?
> 
> I collect packages from various places, make a yumgroups.xml (yum's analog 
> to comps.xml), and publish my own package groups in my local custom yum 
> repository.  I'd have to rebuild all the collected packages with my own 
> Group: header if install-group membership was keyed off of that header 
> instead of yumgroups.xml.
> 
> Possibly after a careful rethinking of the problem, it would become clear 
> that a Group: header suffices, but right now it's awfully handy to have an 
> easily-edited yumgroups.xml.

The fact is, you need both.

The application developer that publishes on rpm of its app on sf need to
be able to select where it will appear in the rpm classification (via
keywords/categories hints)

The distribution people need to be able to choose the policy that
classifies stuff based on the keywords/names provided by each individual
rpm (and yes this can be a policy as dumb as : the members of the foo
group are bar1, bar2, bar3). This policy includes defining standard
keywords/categories/hints

The sysadmin needs to be able to add its own custom overlay to this
standard policy (Jane's stuff group is ...), either to accommodate his
local users needs or a third-party repo that is not covered by the
standard policy.

Any setup that does not allow in-package hints, distro policy and local
sysadmin overlay will f*-up one of these people.

Cheers,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040526/90e40a70/attachment.sig>


More information about the fedora-devel-list mailing list