On 23/03/2014 22:08, hasufell wrote: > Michał Górny: >> Dnia 2014-03-22, o godz. 15:33:27 Alec Warner <[email protected]> >> 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 [email protected]
