Differences between revisions 13 and 14
Revision 13 as of 2008-11-07 11:09:31
Size: 9094
Editor: AndreasTille
Comment:
Revision 14 as of 2008-11-10 09:23:04
Size: 9180
Editor: AndreasTille
Comment: Added link to paper
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
Please see also [:Blends/Manifesto]. Please see also:
 * [http://cdd.alioth.debian.org/blends Detailed paper about Debian Pure Blends]
 * [:Blends/Manifesto]

?TableOfContents

Debian Pure Blends

Terminology

Debian Pure Blends were formerly known as Custom Debian Distributions. The fact that this name was confusing because it left to much room for speculation that this might be something else than Debian leaded to the rename. Currently the renaming is in process and it might happen that you will find the old name in some places. This will change in a short term.

Debian Pure Blend (in short Blend): a subset of Debian that is configured to support a particular target group out-of-the-box.

name not decided yet: a distribution that is not yet a Blend but aims to become one. These are started with the explicit goal of improving Debian as a whole, consequently all extras 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 Blend 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 Blend (e.g debian-science).

Please see also:

Communication

Mailinglist: discussions about ["Blends"] currently take place on debian-custom@lists.debian.org mailing list.

Irc: #debian-custom channel at irc.debian.org is present

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

Discussion page This wiki page can also be discussed at [:DebianPureBlends/Discussion]

News

  • [:Blends/BugsPages] featuring bugs od dependent packages of a Blend
  • Renaming Custom Debian Distributions to Debian Pure Blens
  • [:Blends/TasksPages] for those Blends who are using blends-dev framwork
  • [http://packages.qa.debian.org/c/cdd.html cdd-dev] framework now used by five CDDs

See [:CustomDebian/PreviousNews] for older News items.

Blends that will be released with Lenny (in Lenny the old name CDD is still used):

If you will get Lenny the following Blends are contained:

Debian internal projects which might profit from the Blends effort:

  • Debi Chem : [:StartSeite/debichem] , a Blend for chemists
  • DebianGIS : http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl , a Blend for Geographical Information and Earth Observation Systems (includes ?"OpenGIS" and ?"GPSTk").

  • DebianLive : Building Live CDs might be simplified by using metapackages of a blend

Debian external projects which might be interested in the Blends effort:

Tools or projects that might be interesting to adopt in the Debian Pure Blends scope

(may be more here http://linuxmafia.com/faq/Debian/installers.html )

Common Issues for Blends

Automatic installation

Using the new DebianInstaller 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 metapackages (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 metapackage approach, as it is fragile and break easily if some dependency is unavailable.

Preconfigure the packages we install

Using three different approaches: (1) use modularized/multilevel configuration were available (desktop-profiles, /etc/apache/conf.d, ...), (2) Load answers into the debconf database before the packages are installed using some home-make script, and (3) 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, when they can't be made to do modularized/multilevel configuration.

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

Note Also take a look at ["DebianCustomCD"] and DebianInstaller/Build. These provide instructions for the building of the actual cd's (rather than meta packages, and most of the other issues mentioned in this page)

Configure default language for all users

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

Making simpler KDE / GNOME (XFree86) reaching and menus

Make a simplier way to elect the window desktop manager for ["XFree86"] (KDE/GNOME) by default or by selection on screen by the user (in a similar way to the ["LILO"] / ["Grub"] boot screens to select to partion to boot).

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

Working on the direct use of KDE programs in GNOME and viceversa (in a similar way to ["alien"]).

See also