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

Re: rpm groups and fedora: a modest proposal

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

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

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.


Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée

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