Customizing Debian: Fork Yours With Debian GNU/Linux ----------------------------------------------------- :Author: Benjamin Mako Hill :Contact: mako@debian.org :Date: Fri, 17 Nov 2004 18:30:00 -0500 :Copyright: `Creative Commons ShareAlike License `_ .. Note:: Intro Slide 1 Introduction of Debian Derivations ----------------------------------- .. Note:: Slide 2 **There are 115 separate Linux distributions based upon Debian.** *INSERT LARGE LIST HERE* There are only ~80 based on Redhat! The Most Recognizable Include ------------------------------ .. Note:: Slide 3 * Knoppix * Linspire (Lindows) * Libranet * MEPIS * Ubuntu * UserLinux * Xandros I'm forgetting more. Introduction to Debian ----------------------- .. Note:: Slide 4 Here's my quick introduction into Debian. Debian Quick Facts: * Debian contains what is approaching 20,000 packages (and growing by 5 each day); * Debian involves the work of 1,000 *official* volunteers; * Debian includes the work of many companies and organizations; * Debian is 100% free software; * Debian has very good package management; But What is Debian? -------------------- .. 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. * Debian: the lumps of code (but which one(s)); * Debian: the volunteers with @d.o email addresses (or larger contributing community); * Debian: the principles, philosophy, spirit; * Debian: the political entity; 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? ------------------- .. 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: * Debian is *both* KDE and GNOME * Debian doesn't release often enough * Debian won't pay someone to do X or Y * Debian doesn't include this (probably non-free) piece of software * Debian doesn't do X fast enough. To Fork Or Not To Fork ----------------------- .. 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): * Freedom to pursue different idea of how things should be done. Forking has some serious drawbacks though: * Reproduction of work in a way that that Free Software was supposedly going to be able to avoid. * Security updates, installer issues, translations, etc Case Studies -------------- .. 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: Ubuntu 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. UserLinux 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. Debian-NP/Skolelinux 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 ---------------------------- .. 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: * Custom software selection; * Custom software configuration; * Software replacement; * Custom installers/environments; Plus: * Gain from others work; * Share your work; Package Selection ------------------- .. Note:: Slide 10 * Task packages * Metapackages 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 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 ----------------------- .. Note:: Slide 12 In my opinion, this is the real meat (and the tough part) of customizing Debian. * DebConf preseeding * Low-priority (or unasked!) Debconf Questions 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. * cfengine tweaks .. 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. - The CDD cfengine tweaks repository -- other ideas. 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 --------------------- .. Note:: Slide 15 * Common repositories * Version Control Magic 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. * UserLinux doesn't do this at all. * CDDs do this some. * Ubuntu does this almost exclusively. Custom Installers/Environment ------------------------------ .. Note:: Slide 16 Examples: * Progeny uses Anaconda, the Red Hat installer, to install their Debian based system. * Knoppix, Morphix, etc. are "Live" distributions meant to be run off a CD. 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. Summary -------- .. Note:: Slide 17 * The problem: Debian is great -- But can't be everything everyone wants it to be at once. * The Answer: Balance the global and local in creating infrastructure to: - Select software - Configure software - Replace software - Install and run software in different ways * The result: - A complex and varied set of approaches. - A single united goal of inter-project and inter-distribution collaboration and Total World Domination.