Le ven, 28/05/2004 Ã 08:01 -0700, Paul Heinlein a Ãcrit : > On Fri, 28 May 2004, Panu Matilainen wrote: > > >> but you'd rather edit a spec file and rebuild an rpm to do it? > > > > Yes. > > It seems to me that the hardwiring solution will lead either to more > bickering among distros or more complexity for upstream developers: > > a) If groups change between distro revs, the package's .spec doesn't > have to maintain a silly set of %if statements to set the correct > group for each distribution release. > > b) The maintainer of the .spec -- who, in an ideal world, is the > upstream developer -- needn't worry about inter-distribution > politics (or take sides) when setting the group header. > > Plus, a separate resource like comps.xml makes it reasonably easy for > a package to maintain multiple group memberships. > > That's not to say that comps.xml is a wonderful solution -- but at > least it allows each distro/rev some independence. Since I do contribute to a repository that targets multiple distributions let me say we *never* had to use any %if tweaks in any of our specs for Groups (and this even with the current sorry state of the Group tag). So this is an absolute non-problem. The problem is : - Group is mono-valuated - there is no smart or even dead-stupid processing of its values - when they are used they are used as-is With multi-values you can have packages belonging to many groups if you want to (or in different groups depending on the focus of the distribution) With even a little processing you can cover distro differences (ie games=amusement=time-wasters), define organisational policies, etc. This is what the freedesktop menu does every day in real-time even. This is what any given mp3/ogg jukebox does with id3 tags. This is software 101. Now one can argue package organization does not deserve the time one might spent fixing the Group mess. But surely if it does it should be fixed properly, not with the hack comps is. As far as I'm concerned a repository is nothing more than a glorified ftp area. It indexes packages for performance reasons - and even then all the index info is pulled from the packages themselves. It's a convenience. A useful one, granted but tools like autorpm were able to work on rawhide even long before apt was ported to rpm. And it is *optional*. The system behaves the same if the rpm was taken from a repository, a CD/DVD, hacked localy in half an hour or delivered via tcp-over-messenger-birds protocols. Policy does not belong at the repository level. Policy is included in the rpm themselves and that's how things should stay. All this incestious mingling of two separate layers for convenience reasons screams future problems to me. It's always much easier to break barriers than untangle the resulting mess. 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?=
