On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote: > While we acknowledge that something like debtags will make a better > long-term solution, we do not think that it is ready yet to completly > replace sections (e.g. because it isn't assured that all packages have > tags). This is why we chose to go ahead and adjust what we have, > instead of hoping that debtags can mature enough in time for squeeze. There are other issues that make debtags not quite suitable to replace sections: for example, the workflow is different. Sections are chosen by maintainers and ftp-masters, while tags are chosen by a mix of people. With the number of tags in the vocabulary approacing 600, we just can't ask maintainer, ftp-masters, noone really, to know all of them, and to know how and when to use them properly. > The new sections are: > ruby Everything about ruby, an interpreted object oriented > language. > java Everything about Java > video Video viewers, editors, recording, streaming > fonts Font packages > gnustep The Gnustep environment > xfce The XFCE Desktop, fast and lightweight Desktop > Environment. > httpd Webservers and their modules > localisations Language packs > debug Debug packages > lisp Everything about Lisp > vcs Version control systems > haskell Everything about haskell > zope Zope/Plone Framework > database Databases > kernel Kernel and Kernel modules I would like to consider this an opportunity to use sections to encode something that fits with their workflow, that is: can we use sections to carry information that only the maintainer and ftp-master can fill in, or information for which it's safe and good that maintainer and ftp-masters have the last say? I noticed that most of the replies to this message are a run to add one's favourite section to the list. Are you sure that you want to go in that direction? Where would it lead except to having a poorer version of debtags? Some of the current sections *are* useful. 'libs' is useful. 'oldlibs' is *very* useful, and I'd like to make a Debian QA tag "depends on a library with section 'oldlibs'", once I find a nice algorithm to compute the set of packages for it. I'm happy that 'locali[sz]ations' and 'debug' are added. All of these section group packages with very specific semanthics: a package manager can hide 'libs' and 'oldlibs', can provide a special way to install 'debug' packages corresponding to normal packages currently installed. Can offer a list of 'localisation' options for currently installed packages. Can warn when trying to install a package that depends on an 'oldlibs' library, or if given a choice between an 'oldlibs' dependency and another one, pick the other one. 'oldlibs' could be renamed to 'deprecated', come to think of it, and include packages that are not libraries but that are still around until we manage to get rid of them. 'text' is useless, and probably 'video' is going to be useless as well. Debtags is what you would use for that information. Putting java libraries into 'java' instead of 'libs' would just make it harder for a package manager to hide libraries. Debtags will work for that, so no big deal, but at the moment 'libs' is nice because it allows me to auto-tag packages from that section, based on reliable information provided by the maintainers. Let's find more semantically sound sections. For example, a section "fringe", that the maintainer can use to signal that the package is being used, but only by few people or in specific environments or fields. We could give specific suggestions on how to consider such packages, for example we could suggest not to openly expose to the internet a 'fringe' server, even if it has no open security bugs. Or given the choice between a 'fringe' dependency and another one, prefer the other one. How about a section for packages that are not maintained upstream anymore? Another one could be a 'data' section for "$FOO-data" packages, like game data, that are always pulled in as dependencies and do not make sense alone. Another thing with a clear semanthic, and that for example package managers could comfortably hide. I hope I didn't take a tangent that is too weird to make sense. But given the premise that sections are useless, rather than just make them more diversely useless, I'd prefer to twist them a bit into something else. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
Attachment:
signature.asc
Description: Digital signature