[Debtags-devel] Updating tags on svn

Enrico Zini enrico at enricozini.org
Tue Aug 9 23:28:37 UTC 2005

On Mon, Aug 08, 2005 at 04:44:51PM +0100, Justin B Rye wrote:

> Enrico Zini wrote:
> 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.)

They could always have both x11::application and x11::applet together.
gaim would qualify for both as well, although for a different reason.

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

Right, although I don't know how easy it is to draw a line: the user
documentation for octave, for example, looks quite like developers
documentation as well.

> > 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"?

Good point.  That 'aux' was kind of 'those stuff you don't wanna see in
your package manager', which doesn't make much sense: I wouldn't mind
redistributing those tags between content and software.

> (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!)

I try with this one:


Libraries are very similar to programs, except you can't run them.  If
you want a quick definition it could be "programs without an entry
point": they contain code without a single well-defined starting point,
whose purpose is to be called by other code instead of humans.

Back to our case: why not content?  Because they are made of code ready
to be executed, which we usually consider to be 'software' rather than
just content.

One may argue that all that can be represented digitally (including
software) can be regarded as 'content', but I don't think that this
arguments gets to anything useful for our categorization purposes.

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

I'd still keep some kind of role for them: I'd like the 'role' facet to
be categorisable for all packages in Debian.

This 'text' was intended for packages which have text content, but which
are not documentation about packages.  Examples are 'anarchy',
'bible-kjv', 'cfi-en' and possibly many more will come in the future.

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

Some themes (like the gtk-engines* ones) actually provide additional
rendering code.

It ended up among software because of:
wrt the comment: "Probably more something like extensions or applets..."

I do agree however that they are probably better understood to have the
role of content or data.

> > 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:?

It's not only about .h files, but also about pre-compiled code found in
the library.  The various -dev packages contain a library of functions
(a .a file that will be installed in /usr/lib) and the header files that
explain how to call them.

So, the main body of the development library is actually the code, with
the .h files being formal documentation on how to use it.

Perl or python modules are a small anomaly in that they are interpreted
and they don't need to be compiled to be run.  However, people tend to
regard them as software when they are installed in /usr/lib/something,
and as source code when they are untarred in their home directory.  Even
if the files are the same, the location seems to matter a lot.

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

They are not necessarily role::sw:server: a server is a program that
imlements one side of some well-defined client-server protocol.  A
daemon instead is a program that runs indipendently from users.

So we can have servers that are daemons (such as apache or samba),
servers that are not daemons (such as swat or gobby) or daemons that are
not servers (such as crond or cpufreqd).

cpufreqd, powernowd and maybe eciadsl are daemons and drivers, but they
don't serve requests from programs.

lpd is a daemon (runs indipendently), a server (serves requests done
using the lp protocol) and a driver (it can drive printers).

gpm is a daemon (runs independently), a server (it has some protocol for
programs to get mouse events from it) and a driver (it drives mice).

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

Why not?  If I want to use my centrino wlan card, I have to install
ipw2200-source.  It's true that I also have to turn it into a kernel
module using module-assistant, but the function of ipw2200-source for me
is indeed the function of a driver.

Especially, if I'm looking for packages to make my new hardware work,
I'd go for selecting the role::sw:driver tag and I'd expect to also find
ipw2200-source among the results.

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

Without discussing on the nature of firmware, I think that the same idea
as before applies here as well: if I'm looking for packages to make my
new hardware work, I'd go for selecting the role::sw:driver tag and I'd
expect to also find usrp-firmware, atmel-firmware or bluez-firmware.

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

It does, but again if I want to make my new printer work, I probably
need some foomatic-filters or similar things.

I'd even go as far as to say that if a package explicitly mentions some
specific brand and model of hardware in its description, it's a very
good candidate for being a role::sw:driver no matter how it works.

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

I totally agree, it's under the wrong facet.  Are you happy with the
previous proposal of moving that to accessibility::input-method?  That'd
make things nicer:

libchewing2: accessibility::input-method, role::sw:shlib
libchewing-data: accessibility::input-method, role::content:data
scim: accessibility::input-method, x11::applet, possibly more
dasher: accessibility::input-method, role::sw:program

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

I agree they have a facet to themselves, but I feel like they call for
tags in other facets as well, like use::gaming (to be renamed in
use::entertaining) or x11::game (as I wouldn't look for packages like
frozen-bubble under x11::application).  Maybe x11::entertainment instead
of x11::game, to include cappuccino, xsnow, xeyes?

> > Let's try to wrap it up into some restructuring proposal:

I'll rework it:

role::aux:data			role::content:data
role::aux:dummy			role::aux:dummy
role::aux:metapackage		role::aux:metapackage
role::aux:shlib			role::sw:shlib
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: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 role::content:data and x11::theme
role::sw:utility		moves to role::sw:program, merging with
x11::entertainment		added
x11::applet			added

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

Fair enough; just don't forget to tell me when you like it, or we risk
discussing it forever :)

Again we have lots of topics in a single mail: if it keeps like this,
should I split in more focused subthreads?



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/20050810/e9ee2e80/attachment.pgp

More information about the Debtags-devel mailing list