Dear Users and Developers of (Custom) Debian Distributions, debtags are not (widely || at all) used by CDDs as the moment. This mail is a call to work and agree on a common way of using debtags. Feel free and invited to forward this email to your Custom Debian Distribution (CDD) development list and join the discussion on debian-custom! Apologies for crossposting (at least I'm subscribed to those four lists...) Please reply only to the debian-custom mailinglist (or _only_ on $your list ;) - if you don't want to subscribe to debian-custom you can follow the discussion on the list at http://lists.debian.org/debian-custom/2005/05/threads.html I will start by trying to describe the broader picture "CDD" first, as I feel it would be benificial to the discussion how to use debtags. At the skolelinux/debian-edu work-meeting in Gütersloh this weekend Jonas Smedegaard and me discussed common problems and solutions Custom Debian Distributions deal with. Our discussions circled around the mantra "Debian-edu/skolelinux should not only give back to Debian but also give back to sideways, ie other CDDs." The three main technical challenges each CDD faces are: 1. select the packages for the CDD 2. tweak them (adapt the package configuration to the CDDs need) 3. create a package archive and install media I will cover this list in reverse order now: In our vision a Custom Debian Distribution is built from one cdd package per CDD (see http://wiki.debian.net/index.cgi?CDDTool for more info on that). That cdd package is not maintained inside Debian but maintained by the CDD. The details of creating the cdd package, a package archive and install media are not covered in detail here as good tools and solutions exists and because we have to solve the first two issues first ;-) Four different strategies should be used to customize/tweak the debian packages to the needs of the CDD, ordered by preference: - use plain debian if possible - use debconf preseeding if possible - use tweaks - see http://wiki.jones.dk/DebianTweaks - repackage Different tools are used by various CDDs to tweak the packages to their needs: - debconf preseeding, ucf ("update configuration file") - cfengine - as one tool to do tweaking (see below) - custom-made scripts CDDs need five layers of configuration (upstream defaults, Debian maintainer changes some, CDD change some more, local admins do changes and user changes), where Debian traditionally only has dealt with four. Common tools and methods to achieve this fifth layer, CDD tweaking, would be useful and are the aim of the CDDTool development. Besides tweaking the configuration to the needs of the CDD (without breaking the upgrade pathes provided by Debian and without breaking the choices the local admin made to further tweak the CDD configuration to her needs), CDDs need a standardized way to select the packages which are part of their distribution (which should be based upon debtags and will be explained in a minute.) Then, there is also FAI (http://www.informatik.uni-koeln.de/fai/), which a.) works on the CDDs _and_ local admin "tweak level" and b.) does much more: FAI is a complete framework which covers all three aspects of CDD creation mentioned above as FAI was created as a tool for local admins to manage a specific (to the needs of a local admin) system infrastructure. With FAI it's possible to tweak packages (using debconf, cfengine and traditional custom-made scripting), FAI also provides a class concept (which is used for selecting packages and configuration and much more), means to select packages and to create a installation media. So currently FAI is not really a complement to CDD but a different, standalone tool. For etch (=post-sarge) it is planned to split the fai package into smaller pieces, which would be an ideal opportunity to make FAI a complement to CDDTool as further details how to split up FAI into smaller pieces have not been designed yet. (And, "btw", there are lots of uses for debtags in FAI, package_config/$CLASS created dynamically using debtags, class definitions by CDDs using debtags, ...) But the fai mailinglist is also cc:ed because many fai-users and developers have experiences and strategies in grouping software and machines... After this rather long prologue, now let's dive into the world of debtags, focussed on being able to select / define the packages for a CDD. Let's start with a quote from http://debtags.alioth.debian.org "The size of Debian increases, and the "Sections:" system has proven unable to scale to keep pace with it. There has been much consensus around a multiple tags per package solution: the Debian Package Tags system is a working implementation." Multiple debtags can be attached to a package, those tags are additive and debtags also supports _different_, additive, http-accessable repositories for tags and tag-definitions, ie from debian, skolelinux/debian-edu and Gnome and KDE, fai users (=local admins), $cdd, ubuntu and $YOU :-) The tool debtags, though still in development, is already in a usable state. What's missing mostly to be useful for and adopted by CDDs are tags, tags and tags. # install debtags (and related tools) and update debtags from the net sudo aptitude install debtags debtags-edit tagcolledit sudo debtags update # to get a quick overview man debtags less /var/lib/debtags/vocabulary # contains tag definitions less /var/lib/debtags/package-tags # "the beef" :-) (contains the tags) # both files get updated when doing "debtags update" # to get a full list of all tags and facets do cat /var/lib/debtags/vocabulary | grep Tag # if you have questions about debtags which are not covered in the faq # at http://debtags.alioth.debian.org/faq.html - please raise them - # the answers will then be incorporated into the faq for the benifit of all 13841 packages are tagged (with tags of various quality, i.e. 3831 packages are tagged "not-yet-tagged" ;) and only 411 different tags exist, which are grouped into 29 debtags-groups called facets. Only 5 of these 411 different tags have a person assigned to it, who is responsible for the tag! These group of tags ("facets") also need more work, for example there is only one tag called "educational" and another tag "desktop", but educational and desktop groups of tags ("facets") are missing. As you can see by looking at the tagged packages a policy is needed to be able to spread debtags to all 13000 packages in debian and to all recompiled (afaik & with different compile options and patches and) packages in ubuntu and other CDDs. Those different tag definitions & the tags themselves will be merged by debtags into one - so if you're thinking of using debtags at $anytime please _now_ join the discussion about a common policy. What should be covered by a policy ? For example: the namespace tags use, common facets of tags, criterias how to decide which tags should be attached to packages, how to tag packages to mark them as "belonging" to a specific CDD, how should specific compile-time-features like ldap, ssl, kerberos, etc. be tagged ? Is web::typo3::mandatory::skolelinux::$someschool a good or a bad way of tagging ? Or would it be better to use web::typo3::mandatory, cdd::skolelinux and local::$someschool ? (Don't forget cdd:skolelinux::$country...) Do we need/want tags like web::typo3::mandatory at all ? (Maybe we should start with "Best practices" and work on a policy later...) http://debtags.alioth.debian.org/ has some job offerings and another todo-list, the jobs related to managing the tags are: - Find a good way to maintain the central Debian tag vocabulary (technical infrastructure, people in charge of it) - Discuss the idea of "Adopting" tags, that is having people who take care of the correctness of the list of packages associated to a given tag (which another point of view compared to checking that all tags associated to a package are correct) (Suggested by Erich Schubert) - Discuss the idea of "Outsourcing" the maintenance of some tags: for example the Gnome and KDE people could take care of maintaining the tag data related to Gnome and KDE. Of course, not only the people of Gnome and KDE should take care of tagging their packages, but also the people of debian, debtags-devel, debian-edu/skolelinux, your $CDD, ubuntu, ..., should work together on tagging packages. 'nuff said to raise your interest in debtags and collaborative tagging ? I hope so :) Now let's do it and start a discussion with the goal of defining a common set of rules, a policy for nameing, grouping and assigning debtags. This shouldn't take us (too) long as there's lots of work that needs to be done after that, every CDD has to define its debtag policy and we together (and seperated) have to define tags and facets and attach them to all the packages... To summarize my impressions of debtags: there is a lot of development work going on on a technical level - what's mostly missing now to use debtags are suitable tags! regards & see you on debian-custom! Holger Levsen with the support and affirmation of the Skolelinux Germany Workmeeting, namely: Jonas Smedegaard Alexander Schmehl Christian Külker David Weichert Fabian Franz Kurt Gramlich Patrick Willam Ralf Gesellensetter Thomas Templin These facets are currently defined (in debtags): Tag: accessibility:: Tag: admin:: Tag: culture:: Tag: data:: Tag: dbtech:: Tag: devel:: Tag: field:: Tag: filetransfer:: Tag: format:: Tag: game:: Tag: hardware:: Tag: hwtech:: Tag: implemented-in:: Tag: interface:: Tag: junior:: Tag: langdevel:: Tag: mail:: Tag: media:: Tag: network:: Tag: protocol:: Tag: role:: Tag: security:: Tag: sound:: Tag: special:: Tag: suite:: Tag: uitoolkit:: Tag: use:: Tag: web:: Tag: x11::
Attachment:
pgpSc_bUwRrIL.pgp
Description: PGP signature