DapperStandardsBase

Summary

The need for a system against which people can certify and can also make derivatives is key to the success of Ubuntu. However, the low takeup of the Linux Standards Base by application vendors suggests that vendors are more interested in certifying systems than collections of libraries and paths. This specification provides a middle road that balances these two needs.

Rationale

Dapper will be supported for five years, which makes it a great platform for vendors who want to support their software on Ubuntu. Ubuntu and Launchpad make it trivial to brand and customize Ubuntu. The conflicting needs of these two use cases require us to define a core of Ubuntu that can be counted on.

The more variables we introduce into the supported system, the more trouble we will have asking vendors to certify. Further, security updates may cause necessary kernel ABI changes causing problems for third party hardware vendors.

Our package naming policy requires that packages that have an ABI change must have a different SOVERSION. Because of this, it is theoretically possible to run a newer version of Ubuntu by including dapper in the sources.list and expect that applications will Just Work. However, this doesn't tell the whole story - configuration file formats may have changed, file locations may have changed (for example, the /usr/doc to /usr/share/doc transition). When something is certified on Ubuntu, there is no reasonable way of capturing all of the depended-on components of the system.

Use cases

Servers

  • Sue from Oracle wants to certify that their DBMS runs on Ubuntu, and they don't want to have to recertify every release or update.

Desktop

  • Seb from Canonical purchased his computer from emachines, which ships a branded version of Ubuntu. He wants to purchase and use third party commercial products that have been certified against Ubuntu.

Hardware Vendors

  • Sally from 3com wants to sell more network cards. 3com cards have hardware acceleration in them that handles multicast packets. The code to feed these is proprietary and not possible to provide in a GPLed driver. Sally wants to solve this problem by providing a network driver for servers running their cards.

Scope

All packages included in main.

Implementation

We have chosen to be conservative when defining the core of Ubuntu.

Supported Branding Scenarios

A branded derivative MUST NOT remove or alter any packages that are installed by the installer. There are three scenarios that are interesting for derivatives:

1. A standard Ubuntu install.

This install includes ubuntu-minimal, ubuntu-standard, ubuntu-sounds, the Linux kernel, and ubuntu-desktop. This environment provides our standard Gnome desktop.

To customise this, a derivative MAY replace the contents of ubuntu-docs and ubuntu-artwork.

2. A standard Kubuntu install.

This install includes ubuntu-minimal, ubuntu-standard, the Linux kernel, and kubuntu-desktop. This environment provides our standard KDE desktop.

To customise this, a derivative MAY replace the contents of kubuntu-docs and kubuntu-default-settings.

3. A minimal Ubuntu Server install.

This install includes ubuntu-minimal and ubuntu-standard. This environment provides a minimum install with no desktop or graphical environment and is suitable for certifying servers and hardware drivers.

Acceptable Brandings

An Ubuntu derivative MAY install additional software from main by default.

An Ubuntu derivative MAY install third-party software by default, but a third party vendor MAY require that software to be removed before accepting bug reports on their software.

If an implementation is certifying against the kernel module ABI, the module MUST either provide updates with each ABI bump, contract with a third party vendor to do this for them (like Canonical Ltd.), or provide binary blobs with module interface components that can be provided in restricted, per the licensing policy.

Examples

If Company X wanted to certify their application against the standard Ubuntu install, they should install that and test their applications. A derivative that added an extra piece of software from main in the default install, and a custom machine management application would still remain certified.

If Company Y wanted to provide a sound card driver for their system, they should install and test against the Ubuntu Server install. Because the Ubuntu and Kubuntu installs only include software from main, software certified against the Ubuntu Server platform remains certified against the desktop environments.

BoF agenda and discussion

Oracle FAQ about linux: http://www.oracle.com/technology/tech/linux/htdocs/oracleonlinux_faq.html

CategorySpec

DapperStandardsBase (last edited 2008-08-06 16:17:15 by localhost)