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


Custom Debian Distributions
Chapter 9 - To do


9.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 metapackages, 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. The subversion repository can be browsed or checked out by by

       svn checkout svn://svn.debian.org/svn/cdd/cdd/trunk

for anonymous users. Developers should check out via

       svn checkout svn+ssh://username@svn.debian.org/svn/cdd/cdd/trunk cdd

The current layout for the repository is as follows:

       cdd -+- cdd -+- branches -+- cdd -+- 0.3.x
            |       |
            |       +- tags -----+- cdd -+- 0.3   [older versions of cdd tools]
            |       |            |       +- 0.3.1
            |       |            |          ...
            |       |            |       +- <latest>
            |       |            |
            |       |            +- doc -+- 0.1   [older versions of this doc]
            |       |                    +- 0.2
            |       |                    +- 0.3
            |       |                        [Since 0.4.1 the doc is in cdd directory]
            |       |
            |       +- trunk ----cdd [code in development for cdd source package]
            |                     |
            |                     +-- doc [this document = cdd-doc package]
            |
            +- projects -+--- med ---+- branches
                         |           |
                         |           +- tags
                         |           |
                         |           +- trunk [development version of Debian-Med]
                         |
                         +- science -+- branches
                         |           |
                         |           +- tags
                         |           |
                         |           +- trunk [development version of Debian-Science]
                         |
                         +- ...
                         |
                         ...

There is a mailing list with subversion changes and a CIA system for tracking changes in the Custom Debian Distributions projects in real-time.


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


9.2.1 Custom Debian Distributions web pages

Most Custom Debian Distributions maintain their own web space under http://www.debian.org/devel/cdd to provide general information which will be translated by the Debian web team. This is a good way to inform users about the progress of a project. A special way to announce what is done and what is planed is the list of yet packaged software and software which is intended to be included. To do this in a nice manner Tobias Toedter t.toedter@gmx.net defined a new tag for Debian-Med in order to ease translation by making use of the gettext functionality. In the meantime, this new tag was extended to be useful for other Custom Debian Distributions as well.

As a result, a new .pot file was created, called debian-cdd.pot. Translators of the web pages should update their .po files and translate this new file into their language. For the translation teams who have already begun to translate the web pages of the Debian-Med Custom Debian Distribution, here is a short explanation of the newly introduced tag and its use. The tag is called project, and it takes a few attributes. The complete (empty) tag looks like this:

     <project name=""
       url=""
       license=""
       deb=""
       anchorid="">
       Here goes the description of the project.
     </project>

The meaning of the attributes is as follows:

name

This is the name of the project which is yet packaged or should be packaged for the Custom Debian Distribution in question. In most cases, you won't have to translate this attribute.

url

This is the URL of the homepage of the project. You will almost never have to do any translational work here. At least I can't think of any.

license

The license under which the project is released. In most cases (e.g. GPL, BSD) you don't have to modify anything here. Some projects use a custom license or there's anything other which requires some more explanation in plain text. Of course, this plain text should be translated.

deb

This is the URL of a Debian package. If the project is available as an official Debian package (i.e. it is included in the Debian distribution or available in the contrib or non-free section) or if the project is being packaged by someone, but not stored on the Debian servers, this attribute is used. If there's no package available at all, this attribute is either left blank or omitted completely. There's no need to change this value in your translations.

anchorid

Every project gets an automatically created HTML anchor. This auto-anchor is created by using the project's name (Convert all ASCII characters into lowercase and replace any other character with the underscore. Silly example: "BioSig - For Everyone" -> "biosig___for_everyone"). If for some reason this is not wanted, the id and name of the anchor can be specified with this attribute. An example of the use of this attribute can be found in other.wml. The project's name is "HARP - HArmonisation for the secuRity of web technologies and aPplications", which is awfully long. The anchorid attribute in this case is set to "harp". Note that you should never have to change anything here, if it is already defined in the English page. If you have to translate the name of the project, the automatic creation of the anchorid will naturally give a different result then the English anchorid. In this case, please use this attribute to manually specify the anchor which should be used, according to the rules above: Convert all (ASCII) characters into lowercase, and replace any other character with an underscore. So in conclusion, you should always use the anchorid attribute if you've translated the name attribute.

The interesting part of the project-tag is the body, between the opening and the closing tag. This is the description of the project, and this is the part where you're going to have to translate the text. The best way to learn the usage of this tag is to have a look at the Debian-Med examples.

Moreover it might make sense to sort the list of projects according to the following keys:

available Debian package

Top most you should list all packages which are just inside Debian and thus (hopefully) included in the metapackage dependencies. This should be followed by the projects which has unofficial packages outside Debian. A last group should list all not yet packaged projects which are interesting for the Custom Debian Distribution. These groups are using a certain green-yellow-red color code.

alphabetically

Inside each of these three groups an alphabetical order is proposed to gain some consistency between all Custom Debian Distributions.

The users who are visiting the web pages will like this comfortable overview ...


9.2.2 Automatically graphing the metapackage dependencies for web pages

The new cddtk contains a tool which allows browsing a Packages file for all packages that are listed in the dependency list of a package.

        pkgtool -p UNCOMPRESSED_PACKAGES_FILE pdeps LIST_OF_PACKAGE_NAMES

This could be used as a start to build the web-pages as suggested above automatically - at least for the packages which are just at the Debian-Mirror. For the unofficial packages and not yet existing packages a fake-Packages following the same syntax could be created and processed with the same tool.


9.3 Debian Package Tags

Debian Package Tags is a work to add more metadata to Debian packages. At the beginning it could be seen as a way to allow to specify multiple sections (called "tags") per package where now only one can be used.

However, the system has evolved so that tags are organised in "facets", which are separate ontologies used to categorise the packages under different points of view.

This means that the new categorisation system supports tagging different facets of packages. There can be a set of tags for the "purpose" of a package (like "chatting", "searching", "editing"), a set of tags for the technologies used by a package (like "html", "http", "vorbis") and so on.

Besides being able to perform package selection more efficiently by being able to use a better categorisation, one of the first outcomes of Debian Package Tags for CDDs is that every CDD could maintain its own set of tags organised under a "facet", providing categorisation data which could be used by its users and which automatically interrelates with the rest of the tags.

For example, Debian-Edu could look for "edu::administration" packages and then select "use::configuring". The "edu::administration" classification would be managed by the Debian-Edu people, while "use::configuring" would be managed by Debian. At the same time, non Debian-Edu users looking for "use::configuring" could have a look at what packages in that category are suggested by the Debian-Edu community.

It is not excluded that this could evolve in being able to create a Custom Debian Distribution just by selecting all packages tagged by "edu::*" tags, plus dependencies; however, this option is still being investigated.

Please write to the list deb-usability-list@lists.alioth.debian.org for more information about Debian Package Tags or if you want to get involved in Debian Package Tags development.


9.4 Enhancing basic technologies regarding Custom Debian Distributions

In section Future handling of metapackages, Section 6.2.5 several issues where raised how handling of metapackages should be enhanced.

Regarding to building metapackages for all Custom Debian Distributions consistently it might make sense to use the following approach:

The method how Debian-Edu currently builds its metapackages from a kind of database (in the tasks directory of the source) was generalised in the packages cdd-dev (Package cdd-dev, Section A.1) and cdd-common (Package cdd-common, Section A.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 metapackages 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 metapackages:

            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 metapackages should provide patches for dependent packages if they need a certain configuration option and the package in question does feature a debconf configuration for this case. Then the metapackage 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 metapackage 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 metapackage 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.


9.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. In fact there exist so many Debian based Live CDs that it makes hardly sense to list them all here. The main problem is that most of them containing special applications and thus are interesting in the CDD scope are out of date because they way the usually were builded was a pain. One exception is perhaps Quantian which is quite regularly updated and is intended for scientists.

The good news is that the problem of orphaned or outdated Live CDs can easily solved by debian-live and the live-helper. This package turns all work to get an up to date ISO image for a Live CD into calling a single script. For the CDD tools this would simply mean that the tasks files have to be turned into a live-helper input file and the basic work is done. This will be done in a future cdd-dev version.


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

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


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


Custom Debian Distributions

21 July 2008

Andreas Tille tille@debian.org