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

Re: rpm groups and fedora: a modest proposal



Le mer, 26/05/2004 Ã 02:33 -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).
> 
> Anyone can generate a comps file, trivially. The groups support in yum,
> for example, can merge multiple comps-format files into one set of
> groups.
> 
> > Like for spec file i18n we need a solution that permits standalone
> > self-contained packages. Anything else will sort-of work with RedHat and
> > be rejected by anyone else.
> 
> standalone packages are slowly becoming obsolete.
> 
> There is no point in discussing groups for standalone packages b/c a
> standalone is not a member of any group by its very nature - it is
> standalone.

Of course not - take very small repositories (like the evo 1.5 one,
arjanv kernel, rpms released by the developpers of a given app, etc)

They do exist. They are very useful. But they shouldn't be required ot
maintain all the infrastructure of a full-blown repo with hundreds of
packages.

Big repos need to standardise common categories. But they should not
decide what rpm comes into which category. A rpm must be able to declare
itself where it hooks.

Again, this is much the same problem as menus, and the freedesktop
people were right to choose a solution where each app can just put a
descriptor somewhere instead of relying on a big centralised standalone
db.

What all those separate rpms need are standard keyword/categories,
nothing more.

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


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