[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]

Custom Debian Distributions
Chapter 8 - To do


8.1 Establishing and using communication platforms

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]
            |
            ...

8.2 Enhancing visibility

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?

Change tasksel policy.
If the packages must be on the first CD feature of tasksel would be dropped all Custom Debian Distributions could be listed under this topic in the task selection list.
Custom Debian Distributions information screen.
Alternatively a new feature could be added to 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.
Provide separate install CDs
By completely ignoring the installation of the official installation CD each Custom Debian Distribution can offer a separate installation CD. This will be done anyway for certain practical reasons (see for instance the Debian-Edu - SkoleLinux approach). But this is really no solution we could prefer because this does not work if the user wants to install more than one Custom Debian Distribution on one computer.
Change overall distribution philosophy of Debian.
This way is concerned to some ideas from Debian developers who took part in Open Source World Conference in Malaga and is explained in Detail in New way to distribute Debian, Section 8.6. This would save the problem of making Custom Debian Distribution visible to users in a completely different way because in this case Debian would be released as its various flavours of 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.


8.3 Debian Package Tags

Debian Package Tags are a really nice feature which should definitely be used in future Custom Debian Distribution related tools.


8.4 Enhancing basic technologies regarding Custom Debian Distributions

In section Future handling of meta packages, Section 6.2.5 several issues where raised how handling of meta packages should be enhanced. Moreover the issue of appropriate user menus as it was explained in section User menus, Section 6.4 has to be addressed.

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.3.1) and cdd-common (Package cdd-common, Section 6.3.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.


8.5 Building Live CDs of each Custom Debian Distribution

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:

Distribution
The original Knoppix CD is based on a mixture of Debian testing, unstable and even packages from other sources than the official Debian mirror. There are Knoppix derivatives like Gnoppix which try to stick to stable or at least to one defined set of Debian packages.
User interface
Knoppix has a highly customised KDE environment which just works as it is. There are efforts to release live CDs with Gnome interface (Gnoppix), XFCE or other desktops which are able to cope with less system resources.
Kernel
There are certain reasons to exchange the kernel of the Knoppix CD like in the ClusterKnoppix-Project which uses an OpenMosix kernel.
Special applications
Most of the Knoppix derivatives aim at providing special applications for the purpose of demonstration, training of a classroom using the Knoppix net-boot feature or just having the favourite application always available by just carrying a CD in the wallet. Examples are:
Knoppix4Kids
Knoppix for Children - connected to Debian-Jr.
LiveOIO
Knoppix with PostgreSQL and Zope to run OIO - interesting for Debian-Med.
ISO image of GnuMed Knoppix
Knoppix with PostgreSQL and GnuMed - interesting for Debian-Med.
Vigyaan
Knoppix for computational biology and computational chemistry containing ClustalX, BLAST (NCBI-tools), Open Babel, EMBOSS tools, GROMACS, Ghemical, PyMOL and others.

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.

Currently re-mastering is a top-down strategy: People who want to build there own Knoppix-based live CD proceed this way

  1. Download a complete ISO image. Even with 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.
  1. Copy the stuff from the CD to a temporary space.
  1. Remove packages which are not needed. This requires some research for packages which are worth removing (regarding the space which is gained) and which are not needed later on.
  1. After these steps (all of these are quite time consuming and need a certain amount of knowledge) some further packages can be installed. In case you want to include some database applications or some other applications that need to write a certain amount of data your are more or less on your own to invent techniques to find out how to do that. Except from some postings in the Knoppix-Mailing list there is no reasonable documentation, how to do this right.
  1. Create ISO image from chroot environment and burn it.

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:

  1. Use debootstrap to build a basic system you could chroot into.
  1. Install Knoppix stuff into chroot environment. This is the hardware detection stuff, the special configuration, etc. After this step the system should be in a state like after step 3. of the re-mastering process above. The tricky part to accomplish this is to build reasonable Debian packages like this:
    knoppix-hardware
    Contains all the hardware detection stuff
    knoppix-x
    Contains stuff from Knoppix which cares for X. This is not necessarily needed for simple rescue CDs.
    knoppix-config
    Special configuration stuff. Please note these packages will be installed into a chroot environment which is not a Debian host system. It might be necessary to change the configuration of some packages installed in this chroot environment which conflicts to Debian policy in a real Debian system. But here we face a special part of our hard-disk (say /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
    Whatever might be needed and is not covered by the things above. Here user support for integrating database applications might be integrated.
  1. Customise chroot environment for intended purpose. This is the same as in the re-mastering step 4. but it could be supported by some tools from knoppix-misc.
  1. Create ISO image from chroot environment and burn it. While this is the same as step 5. but it might also be supported by some nifty tools which would simplify things for anybody wanting to build their own CD.

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.


8.6 New way to distribute Debian

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:

Promotion rules
There was a general agreement that technical implementation of this idea in the package pool scripts / database is not too hard. In fact at LinuxTag Chemnitz 2004 Martin Loschwitz 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.
Reasonable subsets
Once the promotion tools are able to work with sub-setting, reasonable subsets have to be defined and maintained. A decision has to be made (if this will be implemented at all) whether this sub-setting should be done according to the Custom Debian Distribution layout or if there are better ways to find subsets.
BTS support
The Bug Tracking System has to deal with different package versions or even version ranges to work nicely together with the sub-setting approach.
Security
As a consequence of having more than only a single stable each CDD-team has to form a security team to care for those package versions that are not identically with the "old" stable.

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
                                        |
                                        +--->  ...

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]

Custom Debian Distributions

9 April 2004

Andreas Tille tille@debian.org