This page tries to give some guidelines when assigning tags to packages. Some tags are easy to assign, some are rather hard and require a bit more thought and knowledge over the package. Our goal is to have all package tagged consistently, of course.
If you think that a package can be tagged along a facet, but the specific tag is missing, please tag it with the <facet-in-question>::TODO tag, the Debtags team will add the missing tags, if necessary.
If you have other questions or suggestions (missing facets, wrong tags, spelling errors, ontological or other mistakes in the vocabulary), please write an email to the Debtags mailing list on Alioth or leave a comment here.
We try to keep the Debtags vocabulary and this page in sync, please leave a comment if this is not the case.
Additional Tagging Information
Currently debtags-edit displays only the short description of the tags. However for some tags there is a more detailed description available. This information can be found in the file /var/lib/debtags/vocabulary. We have also introduced a field called Hints: where additional tagging hints for the tags are added, it is found in the same file. It is planned to display this information in the tagging interfaces too.
*-doc and *-data Packages
foo-doc packages usually don't have the same tags as the package foo. For example, foo may have commandline interface, but foo-doc talks about foo, not about commandline interfaces.
Tag foo-doc with interface::commandline only if foo is a system to generate parsers for commandline interfaces, and so the documentation's main focus is the topic of commandline interfaces.
So foo-doc won't probably have many tags besides role::content:doc.
foo-data won't probably have many tags besides role::content:data. Don't add other tags to it, unless one could want the foo-data package for some specific reaon besides using foo.
Culture for which the package provides special support.
This facet is quite large and should cover most software development specific cases.
This sub-group is the counterpart of made-of::lang:<lang> and should list the all languages the package can be used with or for.
If the package contains a code generator, in most cases there will be a tag for the target language.
Use this tag if the packages relates in any way to the ECMA CLI (will be Mono in most cases), whether it is a library or a tool: A library would be tagged: libfoo-cil: devel::library, devel::ecma-cli, made-of::lang:c-sharp mono-mcs: devel::compiler, devel::ecma-cli, devel::lang:c-sharp, made-of::lang:c-sharp
Unless the package contains language specific runtime libraries, do not add devel::lang tags for all CLI languages, that's exactly what devel::ecma-cli is for.
An text editor that has special features for software development, like syntax highlighting, code completion and folding etc, use::editin does not include devel::editor, but devel::editor should imply use::editing. Also, if the editor might have the works-with::software:source tag, as well as devel::lang:<lang> tags if the editor is meant for a specific, restricted set of programming languages.
There is a thin line between a featureful devel::editor and a devel::ide.
"foo-dbg" is not devel::debugger. It's useful for debugging foo, but the package is indeed not a debugger, nor a plugin for a debugger, not an interface to a debugger.
Special field that the package belongs to
The programming language that has been used to create the scripts or binaries in this package. Don't confuse with devel::lang! For instance, a Python module written in C will have: python-somecmodule: devel::lang:python, devel::library, implemented-in::c
The kind of user interface the package has (not to be confused with the UI toolkit a package uses!)
Daemons and daemon-like programs, including tools run regularly (by cron) without user intervention. Also, programs typically invoked automatically in response to network events.
Don't use...;-) Tags might disappear without further notice!
The data formats or languages used to make the package
Replaced by implemented-in:: (see above)
Is the package related to mail somehow?
What kind of networking support does this package have?
What network protocols does this package use/support? Please add tags only if the program has "explicit" support for it, it's trivial that an HTTP server uses protocol::tcp and protocol::ip, but not that it provides protocol::http. But a package like tcpdump shoud be tagged with protocol::tcp
The relations between IM protocols vs. IM networks are still debated.
Please choose only one tag from this category. If more than one seems to fit, choose the best one.
A dummy package used for smooth upgrades (so-called transition packages), which can normally be safely removed once the transition has been done
Sometimes also called "dummies", the purpose of these packages is to depend on other packages. Examples:
- desktop meta packages (gnome, kde, kdeartwork etc)
Python meta packages (python -> python2.x, python-barmodule -> python2.x-barmodule)
Application-specific data, like game data packages or other architecture independent data. Those packages will normally not be installed by themselves, but only as dependencies to other packages. Those packages are named *-data by convention.
Sole purpose of the package is, to provide data for the user. For those packages the user is interested in the data itself (as opposed to role::app-data where the data is required by an application).
A library that is only installed as a dependency of other packages and does not provide any useful interface for programmers. The usual C/C++ shlib will get role::shared-lib, its -dev counterpart role::devel-lib.
A code library that can be used directly by developers. Python/Perl/Ruby modules are tagged along this category, since developers can work with them directly. The usual C/C++ shlib will get role::shared-lib, its -dev counterpart role::devel-lib.
A plugin for a program that adds functionality. Mostly a dynamic/shared library with a well-defined interface. Examples are xmms plugins.
Glossy, powerful, user-friendly software. Programs too complex, unfocused or featureful (as perl or the autotools) to be called utilities. Programs whose normal interface is interactive or nonminimalistic (as less, mc, aptitude, mozilla or top). Configuration scripts (as the kernel's or base-config) whose only normal mode is a series of questions and answers. Tools which transform data in intricate, adaptive or highly nonobvious ways (as latex or gcc). Programs which are used standalone, and not in some processing chain.
- Utilities and tools normally run non-interactively, which (for example)
* report the state of the system in some respect (as find); * automate a well defined task (as cp or dpkg-reconfigure); * filter a stream of text or data (as sed); * display data in a simple, non-interactive way (as xloadimage); or * fetch and/or put data by a specific protocol (as rsync), implement a basic client to such a protocol (as ssh), or talk to a daemon.
Also, basic tools which provide generic front ends with bare interfaces (as bash, xterm or login); bare, basic, scriptable, command-line-oriented administration and configuration tools (as dpkg or apt-get); minimalistic dockapps (as wmclock) and other simple X tools (as 9menu); primitive line-oriented tools (as more or ed) controllable by stdin; and other small tools in the utility spirit.
Add this tag if you have tagged a package with full care, so that this package can be used as training data for automatic taggers.
To which bigger F/OSS suite/project does this package belong? To the day, it remains disputed what a suite actually is.
What UI toolkit does this program use? Use also, if the package is a UI toolkit or provides additional widgets for a UI toolkit, bindings to other languages etc.
What is the purpose of the package?
How is the package related to the WWW?
These tags describe what is the kind of data (mime-types, or even processes, or people) that the package can work with.
Please do not tag programs with simple unicode support, doing so would make this tag useless, but only if the editor has special support for it, like code tables etc.
Ultimately, all applications should have unicode support.
What role does this package have in X11?
To download the current tag database, see http://debtags.alioth.debian.org/tags