Le ven, 28/05/2004 Ã 08:23 -0400, seth vidal a Ãcrit : > > > > > > Comps is totally unsuitable since it limits you to whatever packages > > > where known to the distribution at the time of its release. (ie bye bye > > > third-party packages). > > > > Seconded, I seriously hate the idea of *having* to edit some xml file just > > to place a random rpm into some category. > > but you'd rather edit a spec file and rebuild an rpm to do it? Yes. It's no different than rebuilding to change the license tag for example. Why so much hate for grouping metadata ? specs are full of tags that require rebuilding to be changed, and no one is even suggesting to strip them (at least I would hope so) I understand the convenience argument from people that have direct admin access to big package repositories. But if we'd were to take a real poll there are a lot more package maintainers than repository maintainers, and I doubt all the packager lowlife (as opposed to the happy few that move in the rarefied ethereal mists of big repo maintership) would surrender they ability to freely categorise the packages they choose to publish. Unless you advocate a 1-1 mapping between package maintainers and repository owners, which would be a tad rich coming on a list like fedora-devel that has still to make its peace with the all the other big third-party rpm repositories. Let's be honest, centralizing grouping in a few xml files plays the game of the core distributions and bigest repositories. The previous post that actually proposed to dump all packages not installed through yum/apt in lala-lala land had the merit of being clear and coherent with Fedora.us past disregard of other packaging efforts. BTW I could probably play this game via the admin accesses I have at jpackage. But even in the context of a single reposiry like jpackage is, this proposal fails to impress me. Not every project is as thoroughly centralised as Fedora.us - I'd hate to have a grouping file to update each time I submit a new package to the repository. (and I'm not even talking about nosrc.rpm management that is still not really covered by comps.xml) Regards, -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
