[Ichthux-devel] Fwd: let's etch a common way of using debtags for CDDs and beyond!

Raphaël Pinson raphink at gmail.com
Tue May 17 10:44:43 MST 2005


Hi all,

Following the recommendation of the initial poster, because it good, I'm 
forwarding this email here, for the ones who are not subscribed to the 
debian-custom ML. For the ones of you who plan to hack for ichthux, mostly 
with packages and config, I really recommend subscribing to this ML and 
reading the Debian Policy and New Maintainter Guide.

God bless

Raphaël

----------  Message transmis  ----------

Subject: let's etch a common way of using debtags for CDDs and beyond!
Date: Mardi 17 Mai 2005 16:44
From: Holger Levsen <debian at layer-acht.org>
To: debian-custom at lists.debian.org, debtags-devel at lists.alioth.debian.org, 
debian-edu at lists.debian.org, matt zimmerman (Edubuntu) <mdz at ubuntu.com>, mark 
shuttleworth (Ubuntu) <mark at canonical.com>, info at ubuntu.com, 
linux-fai at uni-koeln.de

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::

-------------------------------------------------------

-- 
------------------------------------
Raphaël Pinson - raphink at ichthux.org
http://raphink.multiply.com
http://www.ichthux.org - Christian Linux Distribution
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.crosswire.org/pipermail/ichthux-devel/attachments/20050517/6cc575fa/attachment.bin


More information about the Ichthux-devel mailing list