[Debtags-devel] Updating tags on svn

[Justin B Rye]

Enrico Zini wrote:
> Justin B Rye wrote:
>> Well, to be honest, getting those two to be merged is very low on my
>> wishlist.  But I really would prefer to have fewer rather than more
>> role:: tags.  Take for instance role:sw::applet.  Is it really a
>> useful category?  There are two kinds of dock-apps: 
> 
> Well, applet could be a useful search for someone wanting to decorate
> his desktop with blinkenlights.  In that case, both square little apps,
> gkrellm components or gnome/kde panel applets would be interesting
> matches, and one can then later weed out gnome or kde or wmaker stuff
> for compatibility reasons.

People will want to search for them; and when they're dedicated
panel-apps with a package dependency on some particular panel, it's
the role:: facet's job to help them.  But there are a lot of
packages describing themselves as "dockapps" that work perfectly
well on my own dockless desktop... for those, it's just a particular
style of interface::x11.

(Oh, or x11:dockapp, yes, that's better.)

>> Some of those role::content: types might be candidates for a cull
>> too - if we're going to distinguish them on the basis of what kind
>> of data they're made of, we can do that more effectively by way of
>> the made-of:: facet. 
> 
> Agreed.  The only distinction belonging there is probably doc/userdoc,
> but it can probably be moved elsewhere (like in tags such as devel::doc,
> but we really have only that one to move to and it's not enough).

Do I understand that the distinction between :doc and :userdoc was
there for cases like gnome, gnome2-user-guide, gnome-dev and
gnome-dev-doc, so that users searching for gnome2-user-guide don't
trip over the dev-doc package?
 
> role::aux:data - (Auxiliary) Application-specific data
> role::aux:shlib - (Auxiliary) Shared library

Why aren't these role::content:data, role::content:shlib?  Is the
idea that "aux" means "with a strong package dependency"?

(Also... can anyone tell me exactly what a shlib is?  Clearly it's
developer jargon, and an abbreviation for "shared library", but what
does that include exactly?  So far I've been assuming the tag
equates to "package containing .so files", but this is more or less 
guesswork, because none of the jargon dictionaries and packaging
manuals actually specify.  Please don't tell me the answer; tell me
the URL for a good, clear, public, authoritative definition of the
word "shlib", or if you can't find one, create one!)

> role::content:doc - (Content) Documentation
> role::content:text - (Content) Books and text documents

If fonts, dictionaries, images, audio FX, etcetera can move from
role:: to made-of::, I'm not sure why data, shlibs, and text can't,
in some form... it would take some reorganising, though.

> role::sw:theme - (Software) Themes

Why are these under ::sw: rather than ::content:?  Yes, there may be
accompanying setup scripts, but the same goes for fonts, too...

> role::sw:devel-lib - (Software) Development libraries

This means inert .h files (in foo-dev packages) rather than Perl
modules (in libfoo-perl packages), right?  So why ::sw:?
 
> Honestly, client/server is there because it's useful and we had no idea
> where to put it.

Yes, it isn't a perfect fit in the role:: facet but at least it's
close enough.

>> Actually I don't see understand why it is that we have
>> role::sw:driver or role::sw:input-method.  Drivers are simply
>> role::aux:shlib packages associated with a specific kind of
>> hardware::, aren't they?
> 
> Not necessarily.  From a quick research I found these other options:
> 
>  - daemons (for example in case of USB ADSL modems)

These are just role::sw:server packages, aren't they?  Would pppd
(and lpd, and gpm, and so on) count as role::sw:driver?

>  - kernel module sources

These absolutely aren't drivers.  It might be useful to have a tag
specifically for source packages, given that we also have things
like qmail-src and kernel-source-*.  Or something.

>  - firmware blobs that work as raw data loaded by the kernel

As far as role:: is concerned, it's miscellaneous data; the function
as a driver fits better under hardware::.  If there's something
special about what it's made of, there's a facet for that too...

>  - filters converting postscript data to some printer-specific
>    representation.

I don't even understand why people call these "drivers".  But it
sounds like a job for hardware::printer.

>> And as for input-methods... they might deserve to be specially handled
>> under accessibility:: somewhere, but surely they're just servers?
> 
> Also shared libraries (libchewing2), application data (libchewing-data,
> with the statistical information used by the predictive algorithm),
> full-size applications (such as dasher) or applets (such as the SCIM
> applet to change the current input method.

Just because a dockapp has something to do with configuring input
methods doesn't mean that the package's *role::* in the system is
sw::input-method!  This is a big flashing warning sign that the tag
is under the wrong facet... 

>> If users want to search for a window-manager, they already can -
>> there's an x11::window-manager tag entirely dedicated to the purpose
>> of marking out window-managers. [...]
>
> You have a point: the x11 facet solves the problem for all the X11
> software.  'x11::applet', 'x11::game' and 'x11::theme' could definitely
> fit there.
> 
> That leaves however the problem for non-x11 software, which can still be
> 'game' or even 'theme', and can also be 'driver'.  Driver could stay
> into role, though.

What problem is it a solution to, anyway?  Games already have a
facet to themselves.  The x11::applet and ::theme tags seem
plausible, though the the line between x11 games, screen-toys and
screensavers might be hard to draw.
 
> Let's try to wrap it up into some restructuring proposal:
> 
> role::aux:data			ok
> role::aux:dummy			ok
> role::aux:metapackage		ok
> role::aux:shlib			ok
> role::content:dictionary	moves to made-of::data:dictionary
> role::content:doc		ok
> role::content:font		moves to made-of::data:fonts
> role::content:icons		moves to made-of::data:icons
> role::content:text		ok
> role::content:userdoc		merges into content::doc
> role::sw:applet			moves to x11::applet
> role::sw:application		moves to role::sw:program, merging with
> 				role::sw:utility
> role::sw:client			ok
> role::sw:devel-lib		ok
> role::sw:driver			ok
> role::sw:input-method		moves to accessibility::input-method
> role::sw:plugin			ok
> role::sw:server			ok
> role::sw:theme			moves to x11::theme
> role::sw:utility		moves to role::sw:program, merging with
> 				role::sw:application
> x11::game			added
> 
> And we can safely say that console login managers can be
> 'role::sw:program, use::login', and that we don't have enough packages
> for non-x111 themes[1] to justify adding a tag for them.
> 
> Opinions?  If noone objects, I could start this restructuring like 3
> days from now.

I don't see any obvious problems with this plan, but I'd prefer to
spend longer thinking about it...
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)