Last change 2000-02-24

What is it

The tags

The header of the debian Packages gets a new Tags: field. It is a comma separates list of tags. A tag is '[/$]([0-9][a-z][A-Z]_)+'. There are two classes of tags:

root tags. The first character of a root tag is the '/'. The debian team decides which root tags should exist. There should not be more than 40 root tags. They should be categorizable. (e.g. you could group /c++ /c /perl together into the development group and make choosing the tags easier for the user of debiantags) They shall be very highlevel and abstract. /fun /toy /games or /gnome would be good examples. The idea of the root tags is that you see a list of them, select some of them and get what you want without doing micro management. You can fine tune your selections using package tags. But for a start of your search, the root tags shall eliminate maybe 90% of all the packages you did NOT want.
package tags. The first character of a package tag is the '$'. Then follows the name of the package that owns the tag (This means the maintainer of a package may define whatever package tag he wants to define). Then follows a '_'. Then follows a description. For example the emacs20 package could have a $emacs20_lispplugins tag. all the small emacs lisp plugin packages could then also use the $emacs20_lispplugins tag. The idea of the package tags is that you can now do micro management. And the package maintainers have the possibility to introduce more tags. You can fine tune your selections using the very many package tags.
For example: Once you broke down the huge list of packages using the root tags, you can now look at some packages in the list, see their package tags and eliminate all other packages that do not have that tags.

The official debian archives shall perform checking of .deb files before uploading them as follows: If any of the following list is true, the package is NOT accepted:

package uses a root tag that is not in the official debian root tags database
package uses a package tag of another package that does not use the tag. For example: xeyes uses the $emacs20_notexist tag, which the emacs20 package does not use.

The preliminary list of root tags

/fun /game
/x11 /kde /gnome
/commerce
/web
/network
/development
/programming
/graphics
/audio
/sound
/multimedia
/administration
/server
/documentation
/security
/commercial
/non-free
/non-US
/texteditor
/small
/big

/greatmaintained
/mediummaintained
/badmaintained

/stable
/notsostable
/buggy

/verynew
/experienced
/oldandwisely

Usage of debiantags

You want to know wich package you should install to perform the task you want. Therefor you create a boolean expression out of a list of keywords. Example: You want to create documents with docbook. But not with non-free software!!! So you do:

.oO( I want to write documentation using the docbook format.
and i want to convert it to html.
First lets make the big and easy decisions
to eliminate most of the packages )
# debian-tags --selectionfile mysel --resetfillall
.oO( now mysel is filled with all packages that exist )
# debian-tags --selectionfile mysel --tags_keeponly "(/development or /documentation) and not /non-free"
.oO( everything that didn't match is now deleted )
# debian-tags --selectionfile mysel --list name,info
emacs20 editor and kitchen sink
docbook SGML DTD for software documentation
vi texteditor
emacs20-newsbrowser newsbrowser for our emacs
emacs20-webbrowser webbrowser for your emacs
.
.
.
.oO( hmmm. still too many packages. Let's see what tags they have )
# debian-tags --selectionfile mysel --list name,tags
emacs20 /developing,/programming,/big,$emacs20_lispplugins
docbook /developing,/documentation
vi /texteditor,/developing,/programming
emacs20-newsbrowser $emacs20_lispplugins
emacs20-webbrowser $emacs20_lispplugins
.
.
.
.oO( aeh. i do not really care about those emacs lispplugins... )
# debian-tags --selectionfile mysel --tags_eraseall "$emacs20_lispplugins"
.oO( all packages with the $emacs20_lispplugins tag are gone now. )
# debian-tags --selectionfile mysel --list name,info
docbook SGML DTD for software documentation
vi texteditor
jade James Clark's DSSSL Engine
.oO( hehe not many left! let's see what they do )
# debian-tags --selectionfile mysel --list name,description
docbook SGML DTD for software documentation
The DocBook DTD was developed specifically for computer software
documentation, that is, user manuals and programming references.
It has emerged as a standard DTD in the software industry.
vi Vi is the original screen based text editor for Unix systems.
It is considered the standard text editor, and is available on
almost all Unix systems.
jade The jade engine is a useful tool (in conjunction with a DSSSL style
sheet) for translating SGML documents into other formats. Jade can
currently generate SGML, RTF, and TeX.
.oO( STRIKE! jade is what i was searching for. )
# debian-tags --selectionfile mysel --kill
.oO( i could have also done rm mysel, but i want to be abstract!)
# apt-get install jade

Why do we want it

Debian potato consists of over 600 packages. If you are looking for something special, you can not view the description of each of the packages anymore, because they are far too many. Therefore the packages are put into a tree structure and divided into sections. Sections are base, doc, editors, libs, mail, etc. But what if the tree structure does not reflect the way you are thinking ? You are lost. You will have to read the description of package after package until you find what you are looking for.

THE WORLD IS NOT A TREE!
For example, you have a list of the women you know:

Ann: Small, lightweight, loves tennis
Alice: Small, mediumweight, loves tennis
Madame Number 10: Medium sized, fat, loves football, loves tennis
Unknown lady next door: Tall, mediumweight, loves tennis
Bob's girlfriend: Small, fat, plays cricket
girl from mars: medium sized, mediumweight, plays cricket

small,medium sized,tall are mutually exclusive.
lightweight, mediumweight,fat are mutually exclusive.
So both of them are ok for a tree structure.
BUT loves tennis, loves football, plays cricket are NOT mutually exclusive. that means that some of the women love tennis and football. This is the typical problem with the debian package database. But let's try to build the tree:

Small
- lightweight
  - loves tennis
    - Ann
- mediumweight
  - loves tennis
    - Alice
- fat
  - plays cricket
    - Bob's girlfriend
Medium sized
- medium weight
  - plays cricket
    - girl from mars
- fat
  - loves football
    - Madame Number 10
  - loves tennis
    - Madame Number 10
Tall
- mediumweight
  - loves tennis
    - The unknown lady next door

As you see, Madame Number 10 is more than once in the tree. This is not possible in the debian package database. But if we put her into the tree only once, you will not find her in the other place anymore.
What if a package uses plain X11 but has also a KDE version inside?
What if a package converts docbook but is also a generic SGML parser?
What if emacs is a programming language and a shell and a editor and a web browser and a news browser and a multi language tool and an X11 program and a console program and a tetris game and a psychoanalyst game and and and (you know emacs?)
What if you want a list of all FTP clients no matter if they are X11 or GNOME or KDE or console?
There is only one answer: The current system cannot deal with this problems.

Once i wanted to do some DocBook texts. So i scanned for all debian packages that have the string docbook in their name. I found all of them already installed. I wanted to convert docbook to html. None of the installed packages could do this. It was luck that i found the "jade" package. The name "jade" has nothing to do with docbook. There is no way to search for docbook related packages, wich of course would find the jade package!

I know my explanations maybe terrible english etc. but I hope you understand why we think that we really need some other way of displaying and searching the list of available packages.

The implementation

The changes must be possible without changing EVERYTHING at the same time. So each package that has no Tags: field (initially that's every package) will implicitly get a Tags: field dependent on it's dependencies. i.e. every package that needs xlib will implicitly get a /x11 tag. we can also hack together a file implicitly assigning some tags to some packages. this way we can have a useful tool without changing a bit of debian.

We have parser sources from Marcus Schommer !
debian-tags.pl
old source (if you are curious): tag.pl

please help the project with code, not flame.

Who we are

(erikyyy at erikyyy dot de, Erik Thiele) - Webpage and general discussion
Achim.Kern at gmx dot net, Achim Kern - general discussion
schommer at rdts dot de, Marcus Schommer - perl module for scanning tags with boolean expressions

(erikyyy at erikyyy dot de, Erik Thiele)

back