| Author: | Benjamin Mako Hill |
|---|---|
| Contact: | mako@debian.org |
| Date: | Sun, 17 April 2005 19:00:31 -0400 |
| Copyright: | Creative Commons ShareAlike License |
Note
Intro Slide 1
Note
Slide 2
There are 115 separate Linux distributions based upon Debian.
INSERT LARGE LIST HERE
There are only ~80 based on Redhat!
Note
Slide 3
I'm forgetting more.
Note
Slide 4
Here's my quick introduction into Debian.
Debian Quick Facts:
Note
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.
Note
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:
Note
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:
Note
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.
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.
Note
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:
Plus:
Note
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.
Note
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.
Note
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.
Note
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.
Note
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 backports.org and apt-get.org) 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.
Note
Slide 16
Examples:
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.
Note
Slide 17
Joke: This picture is a little inaccurate because it's not just a two-way relationship between Userlinux and Ubuntu here. This is a love-triangle or really more complex goign on here more.
So far, I've talked about technical solutions that go on here but that's really on the first set of problems and, as engineers, perhaps not even the more difficult one. here are political and social concepts in terms of forking and merging and lots of differnet instiutions that we need to think about.
Note
Slide 18
First, the political issues are largely unaddressed. This is the area we need to put more effort.
We are now seeing distributions of distributions and this making things even more important.
We're an example of a new type of software development that I believe is going to be the next major evolution of the free software. Turning forking into a not-bad thing is going to be a major new step in where things are heading and -- as distributions who are having to deal with this problem -- both the technical, politicla and social solutions that we come up with are going to be major steps.
Note
Slide 19