[gentoo-dev] Re: RFC: split up media-sound/ category

[Duncan]

Maciej Mrozowski posted on Sat, 25 Jun 2011 13:55:40 +0200 as excerpted:

> On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:

>> So tags are in some way related to categories then?
>
> IMHO the best approach is to forget about categories and:
>
> - make package names unique identifiers (it's not that hard, renaming
> stuff in app-xemacs mostly) - categories would serve no purpose as id
> anymore (though may need to be provided as backward compatibility - but
> with symlinks to ebuilds/${PN} inside)

What a beautiful bikeshed we're debating! =:^p

> - move such packages into ${PORTDIR}/ebuilds directory (so that identity
> is ensured on filesystem level) - 'ebuilds' name doesn't seem to be
> reserved anywhere so good candidate imho.
> To those concerned with directory lookup speed (in order to find package
> by name) - generated package index file provided in ${PORTDIR}

Alternatively, just use first letter subdivisions.  Perhaps grouping them 
as ac, df, etc, or whatever granularity seems appropriate, if desired.  
That's a common method of eliminating large-dir issues with otherwise 
flat listings.

> - extend their metadata.xml (no ebuild variables please) with tags in
> accepted format. We should provide dictionary for available tags -
> necessary in order to avoid randomly added system tags - tag could be
> extended when needed - similar policy to global USE flags for instance

Keep in mind that there has historically been extremely high resistance 
to "xml-ifying" anything critical to operational package management, by 
certain highly respected and politically influential gentoo devs.  
There's a reason metadata.xml contains only "ancillary" data, while the 
most important operational data (depends, inherits, src_uri, etc) remains 
as variables within the ebuilds and/or eclasses.

I never tracked who was so stridently opposed and it may well be that 
they've retired now, but there's some people who simply don't consider xml 
a sufficiently robust solution in terms of parsing dependencies AND easy 
error-free human parsability.

FWIW, I agree that it'd be a step backward in terms of human editability 
ease and thus I'd find it a sad day were that to happen, but my feelings 
aren't particularly strong on the issue.

But if packages are indeed uniquely and canonically identified by name 
only and tags are kept as ancillary to the core merge process as 
metadata.xml is now, there shouldn't be a problem with it.

Just a warning that "here be dragons" for anyone thinking about going 
down that path.  Consider reading up in the list archive for past debates 
on the subject.

> - package manager needs to be make aware of tags of course in order to
> allow package list (not tree anymore) searching and filtering (virtual
> package tree can be generated from tag - by number of tag occurrences in
> packages - for instance all packages with tag "kde" could be "shown"
> somewhere within "kde" tag subtree etc)

As long as it's kept out of critical operational functionality... but 
this seems to be getting pretty close, if the "package manager needs to 
be [made] aware of tags".  This would have been unlikely to have gotten 
thru at one point... but as I said, it's possible that opposition isn't 
any longer a factor.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman