Customizing Debian: Fork Yours With Debian GNU/Linux

Author:Benjamin Mako Hill
Date:Fri, 17 Nov 2004 18:30:00 -0500
Copyright:Creative Commons ShareAlike License


Intro Slide 1

Introduction of Debian Derivations


Slide 2

There are 115 separate Linux distributions based upon Debian.


There are only ~80 based on Redhat!

The Most Recognizable Include


Slide 3

I'm forgetting more.

Introduction to Debian


Slide 4

Here's my quick introduction into Debian.

Debian Quick Facts:

But What is Debian?


Slide 5

Meanwhile, we have competing arguments about what Debian is and depending on how you answer that question, a Debian-based distribution could be any number of things.

I've argued in the past that we should define Debian politically and then forget about it. We should work on technical goals between organizations that are inside and outside of Debian without discriminating because this is how we will work together.

One Size Fits All?


Slide 6

The reason there are so many derived distributions is that one size does not fit all.

Debian has enough stuff in it that it can be treated a place to work from rather than a solution. Debian may not be everything for everyone but it can provide the stuff to work from.

Reasons for forking:

To Fork Or Not To Fork


Slide 7

A fork is a split in a software project. There have been some famous forks (emacs, GCC) but it almost always involves both an organizational and political split and a split in terms of code leaving us with two projects and two source repositories.

Forking has benefits (there's a reason people do it):

Forking has some serious drawbacks though:

Case Studies


Slide 8

Three case studies for the night that are experimenting and trying to restructure the "hard fork" in three very different ways to maximize benefits of forking while minimizing the reproduction of work, and other drawbacks:


The closest thing we'll see to a full fork.

  • Funded outside of Debian
  • Goal is to create regular releases and a tighter more integrated desktop environment based on GNOME.
  • Ubuntu splits from Debian every six months (completely) and then send patches back to Debian as they are made but applies them in their own repository.
  • Labor intensive (and requires version control magic) but Canonical has the resources for both.

Technically indistinct from Debian although it releases snapshots of Debian.

Contains a sub-selection of packaging and can be seen more as a trade group for a distributed support model and certifications for a (basically) pure Debian system.

Both of these groups are part of the Custom Debian Distributions Framework which is working inside Debian. That said, they are focusing on adding the infrastructure to do custom package selection and custom package configuration.

What Customizers Want to Do


Slide 9

Just a quick overview to run through first. Then I'm going to go into technical detail. The problems/goals of customizers can be broken down into the following pieces:


Package Selection


Slide 10

Tasksel is the familiar window that pops up at the end of your installation. I'm happy to show that off if people like.

The idea behind both tasksel and a metapackage is that it's a package (often an empty one) that includes dependencies on a lot of other packages and does nothing else. By installing one package, you pull in other packages.

Both tasks and metapackages are functionally equivalent although they're pulled in from a separate places and are treated differently within Debian's package system.

This is the process that both CDDs and UserLinux use heavily. Ubuntu has not ruled out using either but is not currently doing this.


Slide 11

See the next slide for a technical description of how it works.

Debtags is an experimental package selection system that support non-hierarchical tagging of packages. It was initially thought of a replacement for sections but it's become apparent that it's useful for a lot more as well.

What CDDs can do (and area already doing) is tag their packages and then automatically generate metapackages based on debtags data. This is something that some CDDs (Skolelinux, ANGULA) are already doing to a certain extent although the technology transfer works both directions.

Package Configuration


Slide 12

In my opinion, this is the real meat (and the tough part) of customizing Debian.

What is Debconf: If you've used a Debian system and installed packages, you know what Debconf is.

Slide 13 - Examples of Debconf

Debconf is the new common interface for manipulating and configuration Debian packages. Questions are of a certain form and are independent of presentation. Questions are asked at priorities and have default values. They can be translated.

Debconf can be preseeded with values that are other than the default. This can be one way that people can do custom configuration.

Of course, sometimes you want to configure something in a way that the package maintainer did not think of: enter low priority debconf questions.

The idea behind adding low priority questions is that you are creating questions that do not change the default behavior but give you the ability to do a different type of configuration. They can be submitted as "wishlist" bugs on Debian packages.


Slide 14 - example of cfengine tweak

There are situations where you can not get a patch or a question into Debconf (due to an inactive maintainer or a technical disagreement) so you need other options. cfengine to the rescue.

cfegine is a language, much higher level than Perl or python, for managing changes to configuration files. It's a great tool for configuration package automatically and can provide a great way to share changes.

Drawbacks: not policy compliant in Debian (as you modify other packages) but it might be a worthwhile sin especially if you say it's temporary.

Package configuration is the CDD landscape.

Ubuntu does all their configuration changes in the method that follows.

Software Replacement


Slide 15

When all else fails, you make a new package. An example Debian-NP ran into was postfix with some security stuff built in.

Solutions to make this work include using shared repositories to share packages between different groups or indexing engines (like and to list custom packages.

Ideally, you need to also be giving stuff back to Debian and other groups which require that you tell what patches they have applied and which patches they have not. It's complicated by changing upstream version (crazy three way merging) and then complicated again by trying to keep the bug tracking system or systems in the loop on all of this. This calls for magic.

I know two system: one being developed by Canonical built on top of arch which is not ready yet but may be soon and another much more lighter-weight CVS-based system called Coronary by Specifix which seems more geared toward distribution management than distribution branching and merging and solid participation in a larger community.

Custom Installers/Environment


Slide 16


These are more self explanatory and I'm not sure what techniques I can give here except in terms of Live CDs:

There has been some work in merging Live CD and install CD and installed hardware detection, etc. Canonical is working on this in Ubuntu as well with GNOPPIX.

All three projects use the Debian installer. CDDs do it with preseeding and Ubuntu uses preseeding and a customized installer to ask less questions.



Slide 17