[Debtags-devel] Updating tags on svn

[Enrico Zini]

On Sun, Aug 07, 2005 at 01:27:49AM +0100, Justin B Rye wrote:
> Enrico Zini wrote:
> > I was instead considering having role::sw:games, role::sw:window-manager,
> > role::sw:terminal, because I think that role::sw:utility is still not an
> > acceptable catch-all for "anything that you wouldn't shrink-wrap".[1]
> If anything, I'd rather go to entirely the opposite extreme and
> advocate the merging of role::sw:utility with role::sw:application.

It sounds good to me.


> The role:: facet isn't well-suited to the task of describing what
> users are going to do with an application; instead it deals with the
> way packages relate to one another, and "package that provides
> independent executables" is only one role.  There's some trace of a
> difference between role::sw:utility and role::sw:application in
> terms of *how* independent they are... not necessarily enough of a
> difference to have any practical value in searches. 

Right.  When doing a search for some little tool, I'd have no idea if I
should go for utility or application.  And taggers are having big
problems assigning the tag as well.


> 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.


> 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).

What would then remain of the role:: facet?

role::TODO - Need an extra tag
role::aux:data - (Auxiliary) Application-specific data
role::aux:dummy - (Auxiliary) Dummy package used for upgrades
role::aux:metapackage - (Auxiliary) Dependency metapackage
role::aux:shlib - (Auxiliary) Shared library
role::content:doc - (Content) Documentation
role::content:text - (Content) Books and text documents
role::sw - Software you can use
role::sw:client - (Software) Client applications
role::sw:devel-lib - (Software) Development libraries
role::sw:plugin - (Software) Plugin
role::sw:server - (Software) Servers
role::sw:theme - (Software) Themes

Honestly, client/server is there because it's useful and we had no idea
where to put it.


> It's not the "bloat" that I worry about, exactly; I wouldn't object
> to extra role:: tags that genuinely belonged under that facet.  But
> category erosion is a problem, because it makes the system less of a
> system...

I totally agree with you.


> 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)
 - kernel module sources
 - firmware blobs that work as raw data loaded by the kernel
 - filters converting postscript data to some printer-specific
   representation.


> 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.

I do see a reason to put the input-methods under accessibility, though.
It's also an opportunity to take 'accessibility' out of the 'stuff for
disabled people' ghetto, even if there is a risk to instead bring
non-latin-language people into the 'stuff for weird people' ghetto.


> 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.  If people want to search for a
> terminal-emulator, they already can - there's an
> x11::terminal-emulator tag entirely dedicated to the purpose of
> marking out terminal-emulators.
> If we start duplicating the distinctions we've already got into the
> role:: facet, there's no end to the list of things we could add.
> Why not role::sw:text-editor? 

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.

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.


Ciao,

Enrico

[1]
 I found 4 of them:  drupal-theme-marvinclassic, drupal-theme-unconed,
 gforge-theme-starterpack, tdiary-theme: they are all themes for web
 applications, and they could eventually end up in web::theme if needed.
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050807/f44692b9/attachment.pgp