Development

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 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 Debian Installer internals document.

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 Menu Item numbers appendix in the "Debian Installer internals" document 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 git package and run: 

git clone https://salsa.debian.org/installer-team/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 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 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 ubuntu-core-dev or https://launchpad.net/~ubuntu-installer teams (matching the branch URL), then you have write access, and can run: 

bzr checkout lp:...

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

bzr branch lp:...

Specifically, to check out the current branch for Ubiquity: 

bzr branch lp:~ubuntu-installer/ubiquity/trunk/

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 lp:~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.

IRC notification

The CIA bot sits on #ubuntu-installer on irc.freenode.net and notifies us of changes made to some projects. Unlike with a centralised revision control system, this can't (easily) be set up on a single central machine; each committer needs to set this up on their development system, possibly for each branch.

Initial setup:

  • Install the cia-clients package (in Ubuntu as of Hardy).

  • Configure the bzr-cia plugin, in the file ~/.bazaar/bazaar.conf:

    • Set cia_user = USERNAME (USERNAME can be whatever you like, perhaps your normal login name, but make sure that http://cia.navi.cx/stats/author/USERNAME either is already yours or doesn't exist).

    • Set cia_send_revno = true (full globally-unique revision identifiers seem too verbose for IRC).

For each branch:

  • Run bzr cia-project PROJECTNAME in the branch. PROJECTNAME needs to be the same as what everyone else working on that project is using, and should usually be the corresponding Launchpad product name.

  • Make sure that the branch nickname is correct (it should usually be the same as the branch name in Launchpad). Use bzr nick to examine it and bzr nick NICKNAME to set it. Both the project name and the branch nickname will be sent to CIA.

  • The CIA plugin will submit new revisions automatically to CIA. If you are working offline, you can temporarily remove the cia_project option from .bzr/branch/branch.conf. When you get back online, you can use bzr cia-submit to submit revisions manually.

If a new project is involved, tell ColinWatson who can arrange for its commits to show up on #ubuntu-installer.

For contributions to Ubiquity, Canonical requires copyright assignment. In exchange for assigning copyright to Canonical, you will receive a broad license in return, which will allow you to retain full rights to re-use, distribute, and continue modifying your contributed code. Please ensure you have agreed to the copyright assignment by following the steps outlined at the address below before proposing your contribution for inclusion into ubiquity trunk. We do not want this to get in the way of your contributions, so please contact Evan if you have any questions about this process.

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 lists.ubuntu.com.

Installer/Development (last edited 2019-06-30 09:00:14 by cjwatson)