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?=
