Ubuntu Unravelled

Traditionally, Ubuntu synchronises packages from Debian Unstable. This adds complexity due to the seemingly impossible task of making the unstable into a stable position within six months. However, the current Ubuntu development version, Lucid Lynx, will synchronise its packages from Debian Testing. This does not provide the ‘latest and greatest’ package versions, but a compromise for stability. This is especially important as Lucid is the next LTS release that will be supported for three years on the desktop and five years for the server version.

Debian and Ubuntu have different goals to achieve before releases are declared stable. Consequently, Ubuntu developers often need to make changes to the packages that are coming from Debian. This means that on the next development version of Ubuntu these changes need to be re-evaluated and possibly merged with newer development packages from Debian. This adds an extra burden to the Ubuntu developer; so when possible, all changes are suggested back to Debian for mutual benefit.

In Debian it is common for packages to be maintained by individuals, although on larger packages they are maintained by teams to help share the burden. The package maintainer often feels personal responsibility for the upkeep of this package, and if someone else suggests a change then it is usually the choice of the Debian maintainer whether to adopt the patch. This can be frustrating if you feel that you have a logical patch, but your views differ from that of the maintainer. There is some recourse to override the maintainer, but it is rare and improper. In practice, the maintainers clearly care about the stability of the package and therefore generally make sound decisions.

In contrast, Ubuntu packages are usually maintained by the whole community of developers, although some packages receive their upkeep from a single person or team. In this instance it is best practice to try and contact this person, but there isn’t usually a strict requirement. Non-developers can suggest changes; they just can not upload them to the repositories. Those changes need to be sponsored by a developer with adequate upload privileges. This ensures that the changes are appropriate and allows anyone to contribute.

The standard Ubuntu repositories are called Main, Universe, Restricted and Multiverse. All the content of the shipped ISOs should be in Main or Restricted, as well as some other crucial packages. To upload to Main or Restricted you need to be a ‘Core Developer’. The vast majority of software in Ubuntu is actually in Universe. Much of this software comes verbatim from Debian, but is also largely maintained purely by the Ubuntu community of MOTU [Masters of the Universe] developers. There are approximately 66,020 packages in the repositories for all the current versions of Ubuntu. Somewhere in the region of 16,875 contain Ubuntu changes. A proportion of these are changes that need to be maintained and merged in newer releases, whereas others are bug fixes where the patch may have been sourced from outside Ubuntu and should be included automatically in the next release.

Something Ubuntu is seemingly trying to move to is greater access control on upload privileges. Currently a developer that purely has interest in the window manager KDE can equally upload packages related to the window manager GNOME. One of the benefits of this is that it should mean that eventually it’s easier for potential developers to be granted upload privileges. However, this process has been contemplated for at least two years and we are only starting to see individuals or teams being granted these privileges. Until recently, I believe all those members with this privilege already had legacy privileges from being either a Core or a MOTU developer, although it is the breadcrumbs of future development.

At the moment, for a potential developer to make a change in Ubuntu, they get the source of the package currently in the repositories, add their change, add an entry in the changelog (incrementing the version number), generate a patch in the form of ‘debdiff’ and attach it to a bug in Launchpad. A sponsor will then review the patch, suggest changes and, if satisfied, upload the change themselves. However, this sometimes causes seemingly trivial changes to create a new version, meaning that anybody running the package needs to upgrade their system. This is generally only an issue on the development version, but can cause multiple released versions for minor issues.

Additionally, Ubuntu development is quite tightly coupled with the bzr (aka Bazaar) version control system. In future, it seems quite likely that developers will not directly upload to the repositories in the form of source packages, but work within Launchpad to suggest changes using version control and having someone merge it following review. I’ll bring you more information on this development some time in the future.

Dave Walker is the current Ubuntu UK community leader, and consultant specialising in business IT and telephony systems.