Ubuntu 4.10: Someone Has to Choose the Packages

A large collection of free software is a remarkable resource and an intimidating answer to “what should I install?” There are editors, browsers, desktops, mail clients, libraries, and several ways to perform almost every task. Choice is useful. Choosing enough pieces to make a dependable working system is also work.

Ubuntu’s first release made that selection part of its product. Mark Shuttleworth’s announcement, dated October 20, 2004, presented Ubuntu 4.10, the Warty Warthog release, as a Linux distribution drawing on Debian with a focused default package set and a regular release schedule.¹

The significant object wasn’t merely a Linux kernel on a disc. It was an arrangement of software, installation choices, updates and community support that people could reasonably treat as one system.

That arrangement is easy to undervalue when the applications already exist. The difficult question is which versions work together, which should be installed by default, and who will take responsibility when the answer needs to change.

The first desktop has a version list

Warty’s announcement identifies GNOME 2.8, Evolution 2.0, OpenOffice.org 1.1.2 and Firefox 0.9 with security patches. It also lists XFree86 4.3. These specific names keep the first release separate from later Ubuntu desktops.¹

Firefox 1.0 arrived the following month. It belongs elsewhere in this series, rather than being casually substituted for the browser in the original Warty announcement. A distribution’s version number doesn’t imply that every component’s next milestone has already happened.

The release also promised a six-month rhythm and eighteen months of support for each release. It offered free physical CDs as well as downloads.¹ Those decisions made availability and maintenance part of the proposition.

Free software can still be difficult to obtain over a poor connection. A mailed disc changes the practical route to installation. It is an unglamorous distribution mechanism with consequences that a list of interface features won’t capture.

Shuttleworth’s public announcement credited professional and volunteer maintainers and testers. Ubuntu depended on Debian’s substantial work and on the upstream projects supplying its components. Describing the release as one person’s invention would leave most of the operating system out of the explanation.

A package contains relationships

A package supplies files and metadata for installing a piece of software. Metadata can state which other packages are required and which versions are acceptable. The package manager uses that information to plan a coherent installation.

Debian’s policy documentation describes dependency fields, alternatives and version relations. Ubuntu’s documentation distinguishes the lower-level package tools from the higher-level tools that obtain packages and handle dependencies.²³

These are modern documents used to explain the inherited package model. Their current commands and every present-day option aren’t assigned to Warty. The mechanism matters more here than reproducing a contemporary command prompt.

Suppose a drawing application needs a graphics library. Installing only the application’s files can leave it unable to start. A package relationship gives the requirement a machine-readable description before the user discovers it through an error message.

The application author knows something about the required interface. The distribution maintainer records how that requirement maps to packaged software. The manager can then evaluate it against what’s available and what’s already installed.

This separates an intention from an action. “Install the drawing program” is the user’s intention. Installing the necessary library may be part of the action needed to make that intention coherent.

Four packages, one shared library

Here’s an invented dependency graph. Sketch requires Canvas, and Canvas requires MathKit. A second application, Viewer, also requires Canvas.

Sketch → Canvas → MathKit
Viewer → Canvas

The arrows mean “requires.” They don’t represent launch order or a stream of data through the programs. A dependency diagram becomes confusing very quickly when one arrow is asked to mean everything.

Assume none of the packages is installed. Requesting Sketch implies obtaining three packages: MathKit, Canvas and Sketch. A simple valid dependency-first order installs MathKit, then Canvas, then Sketch.

Request Viewer afterward. Canvas and MathKit are already present, so only Viewer needs to be added under this model. Two applications share one library package without each receiving an independently maintained private copy.

Original CC0 diagram, 2026. Invented packages and acyclic relationships; not a Warty package database or exact resolver implementation.

Give the packages invented compressed download sizes: MathKit 2 MiB, Canvas 6, Sketch 10, and Viewer 4. The first request downloads 18 MiB. The second downloads 4. The total for both applications and their shared prerequisites is 22 MiB.

If separate application bundles each included independent copies of Canvas and MathKit, our simplified accounting would total 30 MiB. The eight-MiB difference is the duplicated library payload. These are teaching numbers, not historical Ubuntu package sizes or a claim that bundling is always inefficient.

Sharing has a maintenance advantage and a compatibility obligation. Updating one library can help several applications, provided they remain compatible. A library change that breaks one application turns the shared relationship into a shared problem.

Versions make the graph a constraint problem

Now let Sketch require Canvas version 2 or later. Let Viewer require a version earlier than 2. If this simplified system allows only one Canvas version to be installed, both requirements cannot be satisfied together.

The issue isn’t ordering. Installing the packages in a cleverer sequence cannot make one version simultaneously belong to two disjoint ranges. The manager needs another solution: a different application version, separately installable library variants, or a changed request.

This is why dependency handling is more involved than following arrows. Real metadata can include alternatives, conflicts and version limits. Debian’s relationship syntax expresses those distinctions.²

Our check enumerates candidate versions 1 and 2. Neither satisfies both invented applications. That confirms the constraint example without claiming to execute the historical package manager’s resolver.

A well-presented failure is useful. Refusing an inconsistent request with an explanation can be preferable to completing an installation that cannot work. The user asked for software, rather than for a meticulously documented collection of incompatible files.

Maintainers can prevent many such situations by selecting and testing compatible versions before publishing a release. That is where the distribution adds value beyond the availability of individual projects. The repository is a set whose relationships have to make sense.

A release is a moving collection made temporarily definite

Upstream projects release on different schedules. A desktop, browser and office suite don’t necessarily finish their next versions together. A distribution has to choose a point at which enough work is ready to call the set a release.

That produces a useful tension. Newer components offer improvements; waiting indefinitely for the next improvement means never shipping. Freezing a selection allows installation media, testing and documentation to refer to a definite target.

Ubuntu’s six-month commitment made this selection repeatable. It offered a schedule around which contributors and users could plan, while leaving the actual integration work to be done for each cycle.¹

A date on a calendar doesn’t verify compatibility. It supplies a deadline and an expectation. Testing, packaging and decisions about what to defer still determine the quality of the resulting set.

The version name 4.10 itself makes the release recognizable as the 2004 October milestone. The contemporary announcement provides stronger date evidence than a modern retrospective table with a conflicting entry. Historical tables deserve checking too; formatting doesn’t confer immunity from mistakes.

Security maintenance isn’t a version-number race

Once a release exists, maintenance becomes a different kind of selection. A fix may need to be applied while preserving the behavior applications already expect. Replacing every component with the latest upstream release can introduce unrelated changes.

The period announcement’s description of Firefox 0.9 with security patches is a useful concrete reminder. A version can receive selected fixes without being replaced by its next major upstream milestone.¹

In general, a backported fix carries a relevant change into an older maintained branch. Evaluating security by the visible upstream version alone can therefore miss what the distribution has done. The packaged revision and maintenance record matter.

The opposite mistake is trusting the release name indefinitely. A support promise has an interval. A system needs current maintenance within that interval and a plan beyond it. Familiarity isn’t a patch.

Original CC0 illustration, 2026. General distribution lifecycle based on Warty’s stated release/support plan; no claim about the exact date of every historical update.

Our diagram separates choosing the initial set, publishing it, and maintaining it. The work continues after the disc has been pressed. A distribution’s most useful decisions can be almost invisible to someone simply opening the browser.

Trying the system is another product decision

The Warty Live CD announcement followed the first release and explicitly referred back to October 20. A live environment offered a way to try the system without treating the first experiment as a full installation commitment.⁴

That has practical limits. A live session and an installed system can differ in storage, performance and persistence. Testing whether a desktop appears and hardware responds doesn’t prove every daily workflow will be satisfactory.

Still, giving people a route to inspect before committing makes the selection more approachable. Installation media, trial media and support channels are parts of the same effort to make a collection usable.

This is why the history belongs alongside applications and kernels. Distribution design affects whether users can reach the software’s useful capabilities at all. A program that exists in a repository and a program that works on somebody’s laptop are different states.

Selection becomes a service

Ubuntu 4.10’s importance lay in making a selected Linux desktop and its continuing care into a clear proposition. It didn’t invent Linux, package management, desktop environments or free distribution. It arranged existing work with defaults, a rhythm and an undertaking to maintain it.

The dependency example shows why that arrangement has technical content. Shared packages reduce duplication, version constraints determine whether a set can coexist, and maintenance has to preserve enough compatibility for the set to remain useful.

I like the modesty of the core problem. Somebody has to decide what belongs together. Somebody has to test it. Somebody has to keep the decision working after installation.

Warty gave that work a release name, a disc and a schedule. A usable operating system is a collection of choices that have survived contact with one another. The animal on the cover was optional. The coordination wasn’t.

Sources

Footnotes

1. Mark Shuttleworth, Ubuntu 4.10 announcement, October 20, 2004. Contemporary primary release date, components, cadence, support and CD distribution. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Debian project, Declaring relationships between packages, current policy. Dependency/version concepts, not a frozen 2004 manual. ↩ ↩²

3. Ubuntu project, Install and manage packages, current documentation. General division of package tools; modern command behavior not assigned to Warty. ↩

4. Ubuntu project, Warty Live CD Released, October 27, 2004. Trial medium announced after the October 20 release. ↩