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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=