Development

Revision 9 as of 2007-01-25 09:25:31

Clear message

Overview

So, you want to help with the Ubuntu installer? Here's a quick tour ...

Ubuntu and its various flavours (Kubuntu, Edubuntu, Xubuntu) have two installers. One is a modified version of the [http://wiki.debian.org/DebianInstaller Debian installer], known as "d-i", and is written in POSIX shell script and C. The other, Ubiquity, is used on our live CD (or "desktop CD"), features a from-scratch user interface design, and has a good deal of front-end code written in Python, but behind the scenes still uses d-i code for many back-end tasks where it's important that we don't end up maintaining two implementations.

Either way, you'll obviously need to know POSIX shell scripting and C to some level, and if you want to work on Ubiquity you'll need to know Python. You should read up on the general design of d-i, and with debconf, which both d-i and Ubiquity use heavily. See the debconf-devel(7) man page in the debconf-doc package for a general introduction to debconf, and then the [http://people.debian.org/~fjp/talks/debconf6/paper/ Debian Installer internals] paper.

In case that seems intimidating, d-i is a very modular system. You don't have to be familiar with all of it to make a useful contribution to some of it. In fact, relatively few d-i developers are familiar with the whole system, and there are always areas that don't have a strong maintainer right now where somebody can usefully jump in. A quality installer is critical to a quality Ubuntu release, and working on the installer is one of the fastest ways into making a direct, significant contribution to release work.

The doc/devel/menu-item-numbers.txt file in the debian-installer source package can serve as a useful map for d-i.

Debian and Ubuntu

When working on d-i in Ubuntu, it can sometimes be a bit confusing to figure out whether a change should be done in Debian or in Ubuntu. While you're welcome to make changes in the Ubuntu installer when it makes sense, it's important to remember that at some point we're going to have to merge the next round of changes from Debian. As a result, it's good to make changes directly in Debian if the Debian d-i team is happy with them. In particular, we try to avoid changes in Ubuntu that affect translations, because merging changes to 50+ .po files is very tedious and time-consuming.

That said, there are certain things on which the Debian and Ubuntu installers differ. These include:

  • rebranding of strings mentioning "Debian" to say "Ubuntu" instead (see the end of DistributionDefaultsAndBranding for a guide to changing translations of "Debian")

  • places where the Ubuntu installer intentionally asks fewer questions, which has always been a strong design goal of Ubuntu where it makes sense
  • support for changes in other parts of Ubuntu (e.g. different udev setup, different kernel packaging, different default boot options)

  • extra features that haven't yet made it into Debian for various reasons (e.g. Kickstart support, which is waiting for busybox changes that cause space problems in certain kinds of installation media supported by Debian)

  • extra features that have been discussed and, at least for now, refused by Debian (e.g. automatic mounting of partitions)
  • changes that are expected to make it into Debian eventually, but which aren't there at the moment to avoid interfering with release plans (e.g. console-setup)

Feel free to ask me (ColinWatson) about specific changes, since I've been doing this since the start of the Ubuntu project and generally have good historical context.

Revision Control

It's useful to have checkouts both of Debian d-i (which you can get all in one big piece) and of the Ubuntu installer components you're working on (which have to be fetched individually).

For Debian, install the subversion package and run:

svn co svn://svn.debian.org/svn/d-i/trunk d-i

For Ubuntu, the process is complicated by the fact that packages not branched from Debian have their revision control in different places from those that are. Unbranched packages typically live in http://bazaar.launchpad.net/~vcs-imports/PACKAGE/trunk/ or http://bazaar.launchpad.net/~vcs-imports/PACKAGE/main/, while branched packages typically live in http://bazaar.launchpad.net/~ubuntu-core-dev/PACKAGE/ubuntu/. The [https://launchpad.net/projects/d-i d-i project page in Launchpad] and the index branch in http://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/dists/ may be helpful to find where the current branch for a given package is; you can use [http://people.ubuntu.com/~cjwatson/update-config update-config] in a checkout of the index branch (update-config configs/devel) to keep all its contents up to date.

Unfortunately, there are still some Ubuntu installer packages not in revision control at all, and these are managed solely by package uploads to the Ubuntu archive; source for these can only be fetched using apt-get source PACKAGE. Fixing this is an ongoing process.

To check out an Ubuntu branch, no matter where it is, you'll need to install the bzr package. You may or may not have write access to the branch. If you are in the [https://launchpad.net/people/ubuntu-core-dev ubuntu-core-dev team], then you have write access, and can run:

bzr checkout sftp://bazaar.launchpad.net/...

If not, you need to create your own branch like this:

bzr branch http://bazaar.launchpad.net/...

If you create your own branch, you'll need to push it somewhere if you want it to be merged into the main Ubuntu branches. The easiest approach is to push it to the Launchpad supermirror like this:

bzr push sftp://bazaar.launchpad.net/~YOUR-LAUNCHPAD-USERNAME/PACKAGE/BRANCH-NAME

Once you have done this once, you can just use:

bzr push

See http://bazaar-vcs.org/ for more information on bzr.

Starting points

Coordination

Feel free to join the #ubuntu-installer channel on irc.freenode.net to discuss the Ubuntu installer, or use the ubuntu-installer mailing list on [https://lists.ubuntu.com/ lists.ubuntu.com].