Announcing Debian Package Tags

Enrico Zini enrico@debian.org
Mon, 28 Apr 2003 21:38:31 +0200


--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 28, 2003 at 12:30:54PM -0400, Colin Walters wrote:

> Wow, this looks very cool!  Great work.

Thanks!  To you and all the other wonderful people who wrote with great
feedback and enthousiasm: it's been an exciting day after the announce
for me!


> 1) In general what work do you see remaining to do before Debian can
> adopt this system?  It would be nice to make aptitude aware of these
> tags for example.=20

Reusable C++ code is already in tagcoll, ready to be picked up by
aptitude and apt-cache.  I'm also willing to work with them for anything
they might need for the integration.

For the "what work do you see" part, it all depends on what is the best
way for Debian to adopt the system.

In a couple of days, maybe tomorrow already, I plan to upload the two
packages in sid.  After that, any program using tags can depend on
debtags and read /var/lib/debtags/package-tags .  That's it.

That may probably be all the necessary adoption we need for having tags
in debian, however there will probably be issues: what about CD
installations where no network is available?  How do they access the
tags database?  How often will we have vocabulary updates?  What if
debtags goes into stable and users won't be able to update it (and the
vocabulary it contains) as often as required?  What about unattended
installs: who will run "debtags update" on them?

These are some of the issues I can think of, but other people will
surely have more insight than me: I have designed the first step, now I
hope that some of the big debian daddies can show me the direction to
take for the next.

My proposal at the moment is to just start using it in sid the way it
is, and then see what happens.


> 2) Do you forsee tags being maintained outside of the packages in the
> future?  For developing the tag system this makes sense, but it seems to
> me that maintainers should have more direct control over this somehow.

We've been thinking about having the maintainers responsible for the
tagging of their packages, with the risk of ending up with untagged or
poorly tagged packages and lots of bugs in the BTS.  We also have been
thinking about how to implement some cooperative editing structure, with
the risk of having anonymous people doing the mess instead. :)

We probably need a mixture of both.

We could add a Tags: field to debian/control, and we could merge that
information with the one coming from the cooperative edit.  The tagcoll
utility is even able to do such merges, right here, right now.

This is another of the issues that need some more in-field experience to
see what design decisions should be taken next.


> Further, I'd like to add a new tag to the vocabulary for use with Debian
> Desktop; this tag would reflect the overall "specialization" of the
> package.  A lot of packages in Debian are highly specialized,

Assigning such a tag, however, would be quite subjective: I might think
that every law-related package is "specialized", while the debian-lex
people would rather consider "specialized" any of the packages currently
tagged with "devel".

This kind of tagging should not be done at the debian core level, which
needs the maximum level of objectivity because it does not know its
users, but rather by the various subdistros.

In this way, debian-{jr,med,edu,lex,*}, the metadistros, the Morphix
modules and the local-school-specific debian flavour built by the
ministry of education of some small country, they could all define their
own idea of what is "specialized" and what not.

This brings me to the idea of having a custom tag vocabulary that is
merged with the central one.  And I like it so much!  I'll implement it
tomorrow as soon as I get up :)

Thanks!


Yours truly,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+rYM39LSwzHl+v6sRArD1AJ9JvQ7jWrMyp1l1++wKvw4WaooA4QCdFprY
seB1/dFpcS3oZrwY6fCuz9E=
=weyw
-----END PGP SIGNATURE-----

--NzB8fVQJ5HfG6fxh--