Re: [gentoo-dev] RFC GLEP 1005: Package Tags

[Alan McKinnon]

On 23/03/2014 22:08, hasufell wrote:
> Micha³ Górny:
>> Dnia 2014-03-22, o godz. 15:33:27 Alec Warner <antarus@g.o>
>> napisa³(a):
>
>>> https://wiki.gentoo.org/wiki/Package_Tags
>>>
>>> Object or forever hold your peace.
>
>
>> I'd honestly prefer that -- if we should really keep tags in the
>> tree -- to do that with a single 'metadata/tags' file or some kind
>> of hierarchy there. Keep them outside the package directory --
>> bind packages to tags, rather than tags to packages. Keep all the
>> commits in a single place without altering the ebuild work flow.
>
>
> That sounds better. That way it is also easier to get some
> consistency. E.g. tags can be discussed... but adding packages to tags
> is up to the maintainers.
>
> The GLEP should maybe cover a basic set of tags. Then projects like
> games, science etc could add their sets as well which may be a bit
> more specific... instead of random maintainers adding random tags.


Regular user/sysadmin chipping in:

This topic seems a lot like a solution seeking a problem to solve, or
alternatively a dev is looking for an easy way to describe stuff. Not
that there's anything wrong with that, but the proposal as written is
way too vague to be useful.

Tags work best when they describe narrow, clearly defined attributes,
and the thing they are applied to can have one, two or more of these
attributes or sometimes even none. Music and movie genres are an
excellent example - there are only so many of them and for the most part
one can tell whether a tag really is a genre or not.

Nothing resembling such limits are proposed in this GLEP, there's not
even a recommendation of what the tags will describe or how everything
will be tagged equally. What happens if someone zealously over-tags all
of gnome and the same thing doesn't happen for kde? Does kde just not
show up in tag searches anymore?

So this just seems like a nice-to-have that hasn't been properly thought
through. The main stated use of it is for packages that logically belong
to more than one category. So instead of a general catch all, do
whatever you want mechanism, let's rather solve that exact problem by
for example adding a specific field to metadata eg "supplementary
categories". Pick those that apply from a clearly defined list and store
the data in a clearly defined place.

Such a thing can be made more generic, by making it a clear mechanism to
describe extra metadata and the things to be described go through a
defined process first before making it into the list. this concept is
not present in the GLEP as currently written.

-- 
Alan McKinnon
alan.mckinnon@×××××.com