[if help is needed with following the proposal below: a list of tags and
their description can be found at:
* http://debtags.alioth.debian.org/tags/vocabulary.gz
* /var/lib/debtags/vocabulary (if you have debtags installed)
* http://packages.debian.org/about/debtags (formatted on the web)
and can be searched with 'debtags tagsearch' or using the tag editor
at http://debtags.alioth.debian.org/edit.html in the 'all' and
'search' views]
Hello,
The way I see it, the last thread on sections has opened a bit of a can
of worms: now first everyone will want a section for their favourite
topic, then there is going to be a fight on which one to pick in case
packages that could belong to more than one section. Been there, done
that :)
While I see a list of well defined sections that could still make a lot
of sense and carry a very practical meaning (namely, libs, libdevel,
deprecated (former oldlibs), debug, locale, kernel and data (for
foo-data packages)), other sections are clearly minor and belong
elsewhere (like the programming language for a library).
You said that debtags cannot yet replace sections because it is not
assured that all packages have tags: you have a point. Let's take care
of it.
I say that with the number of tags in the vocabulary approacing 600, we
just can't ask maintainer, ftp-masters, or anyone really, to know all of
them; but I can certainly come up with a 'core' list of tags that are
well defined enough, and that we can safely expect maintainers to know
about.
This is what I have to offer:
* The proposal
At the end of this mail is the list that I propose: it's 138 of them,
but grouped as they are, they should be quite clear to grasp. I
consider these groups of tags (debtags calls them facets) to be mature
and uncontroversial enough to be made official and to ask maintaners to
take care of them.
Besides proposing the tags, I offer to implement these three features
within a month from when we agree on a way for maintainers to add them
to the control file:
- For packages with no tags in the control file, take the tags from the
review tag set as we have now
- For packages with tags in the control file, take tags in facets
{role, implemented-in, devel, interface, uitoolkit, accessibility,
admin} from the control file, and all the other facets from the
reviewed tag set.
- Provide a way for maintainers to show differences between the tags in
their control file and the submissions on the debtags web interface,
to be used as a sort of hint
I also offer to write lintian tests to ensure some consistency (role::*
must be there, implemented-in::* must be there if role::program is
there, and so on).
Note that this proposal can be implemented right now, as it introduces
new functionality without interfering with the existing one.
* Future developments
In the future more groups of tags can become 'core', after a round of
discussion, polishing, and testing. This discussion and polishing can
be done in the debtags side, without bothering/boring ftp-masters.
Tags first in the line to become core could be, for example, game::*,
hardware::*, mail::*, web::*, x11::*.
Some other groups of tags (biology::*, field::*, junior::*, made-of::*,
protocol::*, scope::*, suite::* and more) are probably better left to be
managed by groups of field experts. The gnome/kde team is probably
better than any single maintainer in deciding what should have the
suite::gnome/kde tag. Similarly, debian-med or debian-science people
can be called to have a say on tags of their interest.
Also, some tags like those in use::* or work-with::* are better assigned
the other way round, with people picking one tag and working to make
sure that the list of packages with that tag makes sense.
I am happy to come up with a workflow that allows such groups to have
the final say on their tags, and get the result integrated with the
rest: there are already several items in my todo-list that go in this
direction. Maybe, even if game maintainers will easily be able to pick
a game::* tag, we will even decide that it will make more sense, for
consistency, that game::* tags will be managed by the Debian Games team.
But this is for the future. For now, let's stick to the short term
proposal.
* The list
Role of the package in the archive (mandatory for all packages):
role::app-data - Application Data
role::data - Standalone Data
role::debug-symbols - Debugging symbols
role::devel-lib - Development Library
role::documentation - Documentation
role::dummy - Dummy Package
role::kernel - Kernel and Modules
role::metapackage - Metapackage
role::plugin - Plugin
role::program - Program
role::shared-lib - Shared Library
role::source - Source Code
Language that the package is implemented in (mandatory for all packages
mostly consisting of software):
implemented-in::ada - Ada
implemented-in::c - C
implemented-in::c++ - C++
implemented-in::c-sharp - C#
implemented-in::ecmascript - Ecmascript/Javascript
implemented-in::fortran - Fortran
implemented-in::haskell - Haskell
implemented-in::java - Java
implemented-in::lisp - Lisp
implemented-in::lua - Lua
implemented-in::ml - ML
implemented-in::objc - Objective C
implemented-in::ocaml - OCaml
implemented-in::perl - Perl
implemented-in::php - PHP
implemented-in::pike - Pike
implemented-in::python - Python
implemented-in::r - GNU R
implemented-in::ruby - Ruby
implemented-in::scheme - Scheme
implemented-in::shell - sh, bash, ksh, tcsh and other shells
implemented-in::tcl - Tcl, Tool Command Language
User interface (mandatory for all packages mostly consisting of
software):
interface::3d - Three-Dimensional
interface::commandline - Command Line
interface::daemon - Daemon
interface::framebuffer - Framebuffer
interface::shell - Command Shell
interface::svga - Console SVGA
interface::text-mode - Text-based Interactive
interface::web - World Wide Web
interface::x11 - X Window System
User interface toolkit (for packages with tags interface::{3d,
text-mode, x11}):
uitoolkit::athena - Athena Widgets
uitoolkit::fltk - FLTK
uitoolkit::glut - GLUT
uitoolkit::gnustep - GNUstep
uitoolkit::gtk - GTK
uitoolkit::motif - Lesstif/Motif
uitoolkit::ncurses - Ncurses TUI
uitoolkit::qt - Qt
uitoolkit::sdl - SDL
uitoolkit::tk - Tk
uitoolkit::wxwidgets - wxWidgets
uitoolkit::xlib - X library
Role in the context of software development (as needed):
devel::bugtracker - Bug Tracking
devel::buildtools - Build Tool
devel::code-generator - Code Generation
devel::compiler - Compiler
devel::debian - Debian
devel::debugger - Debugging
devel::doc - Documentation
devel::docsystem - Literate Programming
devel::ecma-cli - ECMA CLI
devel::editor - Source Editor
devel::examples - Examples
devel::i18n - Internationalization
devel::ide - IDE
devel::interpreter - Interpreter
devel::lang:ada - Ada Development
devel::lang:c - C Development
devel::lang:c++ - C++ Development
devel::lang:c-sharp - C# Development
devel::lang:ecmascript - Ecmascript/JavaScript Development
devel::lang:fortran - Fortran Development
devel::lang:haskell - Haskell Development
devel::lang:java - Java Development
devel::lang:lisp - Lisp Development
devel::lang:lua - Lua Development
devel::lang:ml - ML Development
devel::lang:objc - Objective-C Development
devel::lang:ocaml - OCaml Development
devel::lang:octave - GNU Octave Development
devel::lang:pascal - Pascal Development
devel::lang:perl - Perl Development
devel::lang:php - PHP Development
devel::lang:pike - Pike Development
devel::lang:posix-shell - POSIX shell
devel::lang:prolog - Prolog Development
devel::lang:python - Python Development
devel::lang:r - GNU R Development
devel::lang:ruby - Ruby Development
devel::lang:scheme - Scheme Development
devel::lang:sql - SQL
devel::lang:tcl - Tcl Development
devel::library - Libraries
devel::machinecode - Machine Code
devel::modelling - Modelling
devel::packaging - Packaging
devel::prettyprint - Prettyprint
devel::profiler - Profiling
devel::rcs - Revision Control
devel::rpc - RPC
devel::runtime - Runtime Support
devel::testing-qa - Testing and QA
devel::ui-builder - User Interface
devel::web - Web
Accessibility support:
accessibility::input - Input Systems
accessibility::ocr - Text Recognition (OCR)
accessibility::screen-magnify - Screen Magnification
accessibility::screen-reader - Screen Reading
accessibility::speech - Speech Synthesis
accessibility::speech-recognition - Speech Recognition
Role in the context of system administration:
admin::accounting - Accounting
admin::automation - Automation and Scheduling
admin::backup - Backup and Restoration
admin::benchmarking - Benchmarking
admin::boot - System Boot
admin::cluster - Clustering
admin::configuring - Configuration Tool
admin::file-distribution - File Distribution
admin::filesystem - Filesystem Tool
admin::forensics - Forensics and Recovery
admin::hardware - Hardware Support
admin::install - System Installation
admin::issuetracker - Issue Tracker
admin::kernel - Kernel or Modules
admin::logging - Logging
admin::login - Login
admin::monitoring - Monitoring
admin::package-management - Package Management
admin::power-management - Power Management
admin::recovery - Data Recovery
admin::user-management - User Management
admin::virtualization - Virtualization
Ciao,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
Attachment:
signature.asc
Description: Digital signature