Custom Debian Distributions

Terminology

The following terminology has settled in, thanks to various threads on debian-devel@lists.debian.org:

Custom Debian Distriution (CDD): a subset of Debian that is configured to support a particular target group out-of-the-box.

CDD in development: a distribution that is not yet a CDD but aims to become one. These are started with the explicit goal of improving Debian as a whole, consequently all extra's they offer will either become part of Debian, or are temporary workarounds to solve a need of the target group which can't be solved within Debian yet.

Flavor: upon installation of a CDD there often is a choice, depending on the particular use, about what set of defaults to use. A flavor is the name of such a set. (e.g. Skolelinux has flavors for main-server, workstation, and thin-client-server)

Subproject: group of people within Debian working together on a common purpose. In most cases this common purpose is either some specific functionality (e.g. debian-multimedia) or a CDD (e.g debian-enterprise).

Communication

mailinglist: discussion about CDD's currently takes place on debian-devel@lists.debian.org. Subjectlines should start with [custom ], thus indicating that the email concerns Custom Debian Distributions.

wiki: used to document the outcome af discussions on the mailinglist.

News

[http://www.debian.org/devel/debian-nonprofit/News/2003/20030717 Report from debcamp Custom Distribution BOF]

CDD's in Development:

Other Debian Customizations

Common Issues for CDD's

Automatic installation

Using the new debian-installer and a few hooks to get the partitioning we want and the packages we want installed into the hard drive. I'm fairly satisfied with this solution.

Installing the list of package we want

Using meta-packages (ie packages consisting only of dependencies) to install the packages we want. Used hooks in base-config to get them installed during first time installation. Not too happy about the meta-package approach, as it is fragile and break easily if some dependency is unavailable.

Preconfigure the packages we install

Using two different approaches: (1) Load answers into the debconf database before the packages are installed using some home-make scripts, and (2) rewrite/replace configuration files using cfengine at the end of the installation if the package is unable to configure what we want using debconf. I'm fairly satisfied with this solution, but am not sure if the method used to feed the debconf database is the best available. I believe the best option would be to extend all the packages we use to make it possible to configure everything we need using debconf answers.

Automatic X configuration

Using home-brewed script filling the debconf database, and then call dexconf from the xfree86 package to generate the configuration file. The HW detection info is fetched from various packages (discover, kudzu, detect, etc).

CD building

Using a heavily patched version of debian-cd to create the ["CDs"]. Most of the patches is to include the d-i boot floppies. This should now be possible with the standard version of debian-cd, but no one in Skolelinux have taken the time to update our copy of the scripts.

Configure default language for all users

Using a custom script to rewrite config files to modify the default language/locale.

Making simpler KDE menus

Working on a system to make simple menus and change the menu depending on the users group membership.