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

[Wyatt Epp]

On Sat, Mar 22, 2014 at 6:33 PM, Alec Warner <antarus@g.o> wrote:
> https://wiki.gentoo.org/wiki/Package_Tags
>
Ack, this had to happen on a weekend when I wasn't paying attention!
And you beat me to it, too-- I was working on something in this vein,
but wasn't quite satisfied with the design yet.  Oh well.  You're sort
of on the right track, but there are some very important aspects
missing that will make the whole thing collapse with their absence.
(This thread has been in various places, but I frankly don't feel like
finding the relevant snippets, so you get a text dump.  Sorry about
that.)

The first thing missing is aliasing (most proposals for this sort of
system miss this at first; don't feel too bad).  There are many, many,
many cases where you want more than one single tag query to resolve to
the same canonical tag.  The ability to define aliases that take care
of this automatically is critical.  In my notes on this, I had a
global alias file, and users can have an /etc/portage/tag.alias.  It's
just text -- nothing special -- that defines antecedent = consequent
relationships.  This means the antecedent is _replaced_ by the
consequent.  As a quick example, cpp = c++ This also allows for simple
changes to the canonical name.

Second, implication is important for decreasing maintenance burden.
An implication is an antecedent -> consequent relationship where the
consequent is automatically added if the antecedent is present.
Unlike aliasing, the consequent doesn't _replace_ the antecedent.  An
example of this is acpi -> power_management, because acpi is a
distinct aspect of power management, and has value on its own.  Over
time, this significantly lowers the maintenance burden of an expanding
vocabulary and tree.

With that in place, I want to make something clear: consistency in the
vocabulary is absolutely critical.  I cannot overemphasise how
important this is.  Adding tags without any sort of discipline leads
to an unmaintainable vocabulary, which makes the whole thing as
worthless as some people think.  So there needs some sort of basic
canonical list of tags with their descriptions, and yes people should
be expected to be rigourous in how they approach this.  I've attached
a rough draft of descriptions and aliases that I pulled together a
while ago (analogous to /etc/portage/profiles/use.desc).

This is where aliasing becomes essential, because it allows us to
guarantee some amount of consistency.  We're only human and can't be
expected to cover every situation, but there's plenty of low-hanging
fruit in this area.  e.g.:
app = application                       # Alias abbreviation to full tag
editors = editor                        # Make plural -> singular
aliases standard where sensible.
                                        # Rule of thumb 1: "This is a(n)..."
admin = administration                  # Rule of thumb 2: "This is
a(n)... ...tool"
backup = back-up                        # Can use hyphenated forms
benchmark = benchmarking                # As with admin, only gerund form.
cdr = disk_authoring                    # Spaces replaced with
underscores at word boundaries
i18n = internationalisation             # Will need to come to a
consensus on the s/z spelling and make some aliases.
cpp = c++                               # Valid tags should be
restricted to basic ASCII minus spaces (replaced with underscores) for
our own sanity
.net = dotnet                           # This could go either way,
but the leading period makes my Unix blood distrust it.
gamedev = game_development              # "games" becomes ambiguous
with "game" so prefer a more-clear form.
lang = language = programming_language  # Not to be confused with the
i18n language support. Avoid confusion with clear naming
version_control = source_control = vcs  # Well known abbreviations can
be used in place of their expansions
mail = email                            # No sense not being clear
mail_server = mail_transfer_agent = mta # Multiple aliases to the same
thing are acceptable
nntp = {{newsreader usenet}}            # The braced notation denotes
an intersection of two tags.  Need to decide if this sort of alias is
legal.  I'm thinking no, honestly.
sys = system                            # BUT it's in conflict with
@system!  Don't do that.
www = web                               # These are all things that
deal with the web specifically.
apache = apache_module                  # classes of packages that
have their own categories is exactly why this is a good idea.

The above is just an excerpt copied directly from my notes on
aliasing.  Some other stuff:
- Query syntax and semantics can be addressed in greater detail later.
 There's some nice sugar to be had here.
- Likewise, tools.  Something along the lines of quse and equery would
be handy in support of this.
- Aliases for reasonable search terms are not a bad idea.
- I've stated at various points in the past, but categories are
already tags after a fashion.  They're not very good ones, but they're
a good place to start.  Moreover, current metapackages and sets are
somewhat like tags in their own right.
- USEs might also be considered as a source of inspiration. That said,
I don't think anything like conditional tags based on the profile's
selected USE is a good idea.  Don't make this more complex than it is.
- Succinctly, strongly hierarchical tags are a mistake and will cause
you more grief than you can imagine.  Ontologically, aim for "mostly
flat".
- Limiting the number of tags allowed on a package is a horrible idea;
seriously, don't even consider that-- you would absolutely regret it.
The whole point of this is to allow useful semantic description.
- Crowdsourcing is something that _can_ work, but needs to be
moderated in some way.  It could work well to deputise some trusted
users for this task, similar to arch testing, and they have mandate to
do responsible tag gardening.
- A good maxim for additions is "tag what you see".  If it provides a
library with a lua bindings, then that's probably a good thing to tag.
- Maintainers can be awfully possessive of their packages, but on this
subject I think it would benefit them to unclench a little.  Most
additions should be relatively obvious.
- Per-$PV tagging is honestly probably not necessary.  Sticking it in
metadata.xml seems reasonable for now.

Regards,
Wyatt