Each Custom Debian Distribution has an own mailing list for discussion of
specific development issues. Because there are several common issues between
all Custom Debian Distributions also a common mailing list was created. People
who are interested in working on common issues like building meta packages,
technical issues of menu systems or how to create CDs for Custom Debian
Distributions could subscribe to this list or read
the list archive
.
Moreover the project cdd
on Alioth was
started. This project contains a repository for all Custom Debian Distribution
related work. The current layout for the repository is as follows:
cdd -+-- doc +-- common [this document] | | | +-- med [Debian-Med documentation] | | | +-- junior [Debian-Jr documentation] | + | ... | +-- common [common tools for all CDDs] | +-- junior [junior-* meta packages] | +-- med [med-* meta packages] | ...
If a user installs Debian via official install CDs the first chance to do a
package selection to customise the box is tasksel
. The first
Custom Debian Distribution Debian-Junior is mentioned in the task selection
list and thus it is clearly visible to the user who installs Debian.
In bug #186085
a
request was filed to include Debian-Med in the same manner. The problem with
the tasksel
-approach is that all included packages should be on
the first install CD. This would immediately have the consequence that the
first install CD would run out of space if all Custom Debian Distributions
would be included in the task selection list.
How to enhance visibility of Custom Debian Distributions for the user who installs Debian from scratch?
tasksel
policy.tasksel
would be dropped all Custom Debian Distributions could be
listed under this topic in the task selection list.
tasksel
or in
addition to tasksel
in the installation procedure which presents a
screen which gives some very short information about Custom Debian
Distributions (perhaps pointing to this document for further reference) and
enables the user to select from a list of the available Custom Debian
Distributions.
Whichever way Debian developers will decide to go it is our vital interest to support users and show our users the tools we invented to support them.
It might make sense to maintain also a common Custom Debian Distributions web page under http://www.debian.org/devel/cdd to provide general information which will be translated by the Debian web team.
Debian Package
Tags
are a really nice feature which should definitely be used in
future Custom Debian Distribution related tools.
In section Future handling of meta packages, Section 6.2.5 several issues where raised how handling of meta packages should be enhanced.
Regarding to building meta packages for all Custom Debian Distributions consistently it might make sense to use the following approach:
The method how Debian-Edu currently builds its meta packages from a kind of
database (in the tasks
directory of the source) was
generalised in the packages cdd-dev
(Package cdd-dev
, Section
6.4.1) and cdd-common
(Package cdd-common
,
Section 6.4.2). This approach definitely needs some enhancements to fit
the needs of all Custom Debian Distributions. It might be a good idea to
maintain a more general kind of database than this tasks
directory
approach currently represents for each Custom Debian Distribution. From this
database the control files for all meta packages could be built on demand to
build the necessary files of the debian
directory in the package
build process dynamically. The extra plus would be that it would be easy to
build tools which parse this database to generate docs and websites
dynamically. It would drastically reduce the amount of work for keeping the
project related web sites up to date if this could be done automatically. Some
tools like the following might be easily done to support maintenance and
documentation of the meta packages:
build_cdd-package med bio build_cdd-package junior toys build_cdd-package education [all] build_cdd-wml-template nonprofit <foo> build_cdd-wml-template demudi <bar> cdd-package-info.php?cdd=<foo>&pkg=<bar>
If the database structure is well thought (perhaps using XML or by stealing the format of other databases which are usually used in Debian) not really hard to implement.
Last but not least the special configuration issue has to be addressed. In
general developers of meta packages should provide patches for dependend
packages if they need a certain configuration option and the package in
question does feature a debconf
configuration for this case. Then
the meta package could provide the needed options by pre-seeding the
debconf
database while using very low priority questions which do
not came to users notice.
If the maintainer of a package which is listed in a meta package dependency and
needs some specific configuration does not accept such kind of patch it would
be possible to go with a cfengine
script which just does the
configuration work. According to the following arguing this is no policy
violation: A local maintainer can change the configuration of any package and
the installation scripts have to care for these changes and are not allowed to
disturb these adaptations. In the case described above the
cfengine
script takes over the role of the local administrator: It
just handles as an
"automated-cfengine
-driven-administrator-robot".
If there is some agreement to use cfengine
scripts to change
configuration - either according to debconf
questions or even to
adapt local configuration for Custom Debian Distribution use in general - a
common location for this kind of stuff should be found. Because these scripts
are not configuration itself but substantial part of a meta package the
suggestion would be to store this stuff under
/usr/share/cdd/#CDD#/#METAPACKAGE#/cf.#SOMETHING#
There was another suggestion at the Valencia workshop: Make use of
ucf
for the purpose mentioned above. This is a topic for
discussion. At least currently Debian-Edu seems to have good experiences with
cfengine
but perhaps it is worth comparing both.
A further option might be Config4GNU
from
freedesktop.org but it is not even yet packaged for Debian.
The first step to convince a user to switch to Debian is to show him how it
works while leaving his running system untouched. Knoppix
- the "mother"
of all Debian-based live CDs - is a really great success and it is a fact
that can not be ignored that Debian gains a certain amount of popularity
because people want to know what distribution is working behind the scenes of
Knoppix.
But Knoppix is a very common demonstration and its purpose is to work in everyday live. There is no room left for special applications and thus people started to adopt it for there special needs. This adaptation can have different focuses:
Gnoppix
which try to stick to
stable or at least to one defined set of Debian packages.
ClusterKnoppix
-Project which
uses an OpenMosix kernel.
Knoppix4Kids
Quantian
LiveOIO
ISO image of GnuMed Knoppix
Vigyaan
alioth.debian.org
do some similar projects
exist.
Debix
When the author Goswin von Brederlow brederlo@informatik.uni-tuebingen.de
was asked about his goals he answered: "Debix is a level below knoppix I
would say. If you handle the knoppix debs and scripts you could use debix to
make seemingly writeable cd images out of a tar.gz or a directory containing
the knoppix tree."
Debix is more than one thing:
In cvs (on alioth) is a version of Debix that can be called "proof of concept" of part 1. Work is in progress of changing the build scripts to be modular and flexible so part 2 can be started.
Debix can provide the infrastructure. Knoppix has to supply the debs that should be in a Knoppix set for debix. The 2 parts mean that Debix is suposed as tool to create a live-cd from an existing or hand build system but also a tool that can build such system automatically according to preset rules (list of debs and some cleanup scripts if needed).
Metadistros
It is a little bit hard to get information about this project, because most of the information is in Spanish language.
One piece of the docs which Sergio Talens-Oliag sto@debian.org
has kindly translated
says: "... the main problem is that Debian wants a Debian tool to make
its own LiveCDs but Metadistros wants to give tools to let anyone create a
distribution that can be used as LiveCD and/or installed and be based in
whatever linux distribution the user wants. Anyway, he said that if they can
cooperate in any way they will be happy to do it."
Morphix
ISO's with XFCE4, Gnome2.4, KDE3.1, a game iso and a large number of derivatives are available. Morphix is an Open Source/Free software project, based on Debian GNU/Linux and Knoppix.
So building Live CDs is a common issue for each Custom Debian Distribution and
the goal is to develop a mastering system which drastically decreases the
effort to build such live CDs. To accomplish this goal the debian-knoppix
project on Alioth was created.
Currently re-mastering is a top-down strategy: People who want to build there own Knoppix-based live CD proceed this way
bittorrent
or similar
techniques it makes no sense to download 700MBytes for each new Knoppix version
if you might probably need only half of this size for your intended use.
Moreover regarding to the fact that Knoppix consists mostly of installed Debian
packages you might have nearly all stuff you need on a local (or at least
nearby) Debian mirror with a fast connection.
It would make much more sense to use a bottom-up strategy and master the CD instead of re-mastering. It might even make sense to build a Custom Debian Distribution for itself to build the necessary tools for this mastering a Knoppix-Live-CD approach. The general way would be as follows:
debootstrap
to build a basic system you could
chroot
into.
knoppix-hardware
knoppix-x
knoppix-config
/var/cache/knoppix/etc
) which is not covered by policy. The only
point is to make sure that this knoppix-config
package will not be
installed on a Debian host system (if and only if anything is really needed
which would not comply with the policy).
knoppix-misc
knoppix-misc
.
This approach would have the additional advantage of being portable also to
non-i386 architectures and in fact Fabian Franz FabianFranz@gmx.de
managed to prove
this true for Power-PC architecture.
This section is kind of "Request For Comments" in the sense that solid input and arguing is needed to find out whether it is worth implementing it or drop this idea in favour of a better solution.
At Open Source World Conference in Malaga 2004 there was a workshop of Debian Developers. Among other things the topic was raised how the distribution cycle or rather the method of distribution could be changed to increase release frequency and to better fit user interests.
There was a suggestion by Bdale Garbee bdale@gag.com
to think about kind of
sub-setting Debian in the following way: Debian developers upload their
packages to unstable. The normal process which propagates
packages to testing and releasing a complete stable
distribution also remains untouched. The new thing is that the package pool
could be enhanced to store more package versions which belong to certain
subsets alias Custom Debian Distributions which all have a set of tested
inside the subset distribution which leads to a stable
subset release. The following graph might clarify this:
DD -> unstable --> testing --> stable | +---> CDD_A testing --> stable CDD_A | +---> CDD_B testing --> stable CDD_B | +---> ...
where CDD_A / CDD_B might be something like debian-edu / debian-med. To implement this sub-setting the following things are needed:
madkiss@debian.org
announced
exactly this as "nearly implemented for testing purpose" which should
solve the problem of outdated software for desktop users as a goal of the
debian-desktop project.
A not so drastically change would be to find a common set of packages which are interesting for all Custom Debian Distributions which will obtained from the "releasable set" of testing (i.e. no RC-bugs). This would make the structure above a little bit more flat:
DD -> unstable --> testing --> releasable --> stable | +---> stable CDD_A | +---> stable CDD_B | +---> ...
A third suggestion was given at Congreso Software Libre Comunidad Valenciana:
testing_proposed_updated | | v DD -> unstable --> testing --> stable | +---> stable CDD_A | +---> stable CDD_B | +---> ...
The rationale behind these testing backports is that sometimes a Custom Debian Distribution is able to reduce the set of releasable architectures. Thus some essential packages could be moved much faster to testing and these might be "backported" to testing for this special Custom Debian Distribution. For instance this might make sense for Debian-Edu where usually i386 architecture is used.
All these different suggestions would lead to a modification of the package pool scripts which could end up in a new way to distribute Debian. This might result from the fact that some Custom Debian Distributions need a defined release cycle. For instance the education related distributions might trigger their release by the start-end-cycle of the school year. Another reason to change the package pool system is the fact that some interested groups, who provide special service for a certain Custom Debian Distribution, would take over support only for the subset of packages which is included in the meta package dependencies or suggestions but they refuse to provide full support for the whole range of Debian packages. This would lead to a new layout of the file structures of the Debian mirrors:
debian/dists/stable/binary-i386 /binary-sparc /binary-... /testing/... /unstable/... debian-CDD_A/dists/stable/binary-[supported_architecture1] /binary-[supported_architecture2] /... /testing/... debian-CDD_B/dists/testing/... /stable/... ... pool/main /contrib /non-free
To avoid flooding the archive with unnecessarily many versions of packages for each single Custom Debian Distribution a common base of all these Custom Debian Distributions has to be defined. Here some LSB conformance statement comes into mind: The base system of all currently released (stable) Custom Debian Distributions is compliant to LSB version x.y.
Regarding to security issues there are two ways: Either one Custom Debian
Distribution goes with the current stable Debian and thus the
Packages.gz
is just pointing to the very same versions which are
also in debian/stable. Then no extra effort regarding to security issues is
need. But if there would be a special support team which takes over
maintenance and security service for the packages in one certain Custom Debian
Distribution they should be made reliable for this certain subset.
This reduced subset of Debian packages of a Custom Debian Distribution would also make it easier to provide special install CDs at is it currently done by Debian-Edu.
Custom Debian Distributions
28 July 2004tille@debian.org