[Debtags-devel] let's etch a common way of using debtags for CDDs and beyond!
Holger Levsen
debian-custom@lists.debian.org
Tue, 17 May 2005 16:44:34 +0200
--nextPart3900537.BxlDZdZWey
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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 invi=
ted=20
to forward this email to your Custom Debian Distribution (CDD) development=
=20
list and join the discussion on debian-custom!
Apologies for crossposting (at least I'm subscribed to those four lists...)=
=20
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 th=
e=20
discussion on the list at=20
http://lists.debian.org/debian-custom/2005/05/threads.html
I will start by trying to describe the broader picture "CDD" first, as I fe=
el=20
it would be benificial to the discussion how to use debtags.
At the skolelinux/debian-edu work-meeting in G=FCtersloh this weekend Jonas=
=20
Smedegaard and me discussed common problems and solutions Custom Debian=20
Distributions deal with. Our discussions circled around the mantra=20
"Debian-edu/skolelinux should not only give back to Debian but also give ba=
ck=20
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=
).=20
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 becau=
se=20
we have to solve the first two issues first ;-)
=46our different strategies should be used to customize/tweak the debian
packages to the needs of the CDD, ordered by preference:
=2D use plain debian if possible
=2D use debconf preseeding if possible
=2D use tweaks - see http://wiki.jones.dk/DebianTweaks
=2D repackage
Different tools are used by various CDDs to tweak the packages to their
needs:=20
=2D debconf preseeding, ucf ("update configuration file")=20
=2D cfengine - as one tool to do tweaking (see below)
=2D 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=
=20
minute.)
Then, there is also FAI (http://www.informatik.uni-koeln.de/fai/), which a.=
)=20
works on the CDDs _and_ local admin "tweak level" and b.) does much more: F=
AI=20
is a complete framework which covers all three aspects of CDD creation=20
mentioned above as FAI was created as a tool for local admins to manage a=20
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 (whic=
h=20
is used for selecting packages and configuration and much more), means to=20
select packages and to create a installation media. So currently FAI is not=
=20
really a complement to CDD but a different, standalone tool.
=46or etch (=3Dpost-sarge) it is planned to split the fai package into smal=
ler
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/$CLA=
SS
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 f=
or=20
tags and tag-definitions, ie from debian, skolelinux/debian-edu and Gnome a=
nd=20
KDE, fai users (=3Dlocal 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 a=
nd
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=20
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 =20
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=
=20
are tagged "not-yet-tagged" ;) and only 411 different tags exist, which are=
=20
grouped into 29 debtags-groups called facets. Only 5 of these 411 different=
=20
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 on=
ly=20
one tag called "educational" and another tag "desktop", but educational and=
=20
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=
=20
and other CDDs. Those different tag definitions & the tags themselves will =
be=20
merged by debtags into one - so if you're thinking of using debtags at=20
$anytime please _now_ join the discussion about a common policy.=20
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 attache=
d=20
to packages, how to tag packages to mark them as "belonging" to a specific=
=20
CDD, how should specific compile-time-features like ldap, ssl, kerberos, et=
c.=20
be tagged ?
Is web::typo3::mandatory::skolelinux::$someschool a good or a bad way of=20
tagging ? Or would it be better to use web::typo3::mandatory, cdd::skolelin=
ux=20
and local::$someschool ? (Don't forget cdd:skolelinux::$country...) Do we=20
need/want tags like web::typo3::mandatory at all ? (Maybe we should start=20
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:
=2D Find a good way to maintain the central Debian tag vocabulary (technical
infrastructure, people in charge of it)
=2D Discuss the idea of "Adopting" tags, that is having people who take car=
e of=20
the correctness of the list of packages associated to a given tag (which=20
another point of view compared to checking that all tags associated to a=20
package are correct) (Suggested by Erich Schubert)
- Discuss the idea of "Outsourcing" the maintenance of some tags: for exam=
ple=20
the Gnome and KDE people could take care of maintaining the tag data relate=
d=20
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,=20
debian-edu/skolelinux, your $CDD, ubuntu, ..., should work together on=20
tagging packages.
'nuff said to raise your interest in debtags and collaborative tagging ? I=
=20
hope so :)
Now let's do it and start a discussion with the goal of defining a common s=
et
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=20
packages...
To summarize my impressions of debtags: there is a lot of development work=
=20
going on on a technical level - what's mostly missing now to use debtags ar=
e=20
suitable tags!
regards & see you on debian-custom!
Holger Levsen
=09
with the support and affirmation of the Skolelinux Germany Workmeeting,=20
namely:
Jonas Smedegaard=20
Alexander Schmehl
Christian K=FClker
David Weichert
Fabian Franz
Kurt Gramlich=20
Patrick Willam
Ralf Gesellensetter
Thomas Templin
These facets are currently defined (in debtags):
Tag: accessibility::
Tag: admin::
Tag: culture::
Tag: data::
Tag: dbtech:: =20
Tag: devel::
Tag: field::
Tag: filetransfer:: =20
Tag: format::
Tag: game::
Tag: hardware::
Tag: hwtech::
Tag: implemented-in:: =20
Tag: interface:: =20
Tag: junior::
Tag: langdevel:: =20
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::
--nextPart3900537.BxlDZdZWey
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBCigNhUHLQNqxYNSARAlTNAJ9A30ah00myxN5wzFafRQjkBK2rCgCgjMsw
Zet7yUj1TAbKkNhuE/LT8G0=
=ElGT
-----END PGP SIGNATURE-----
--nextPart3900537.BxlDZdZWey--