DapperStandardsBase
Size: 3353
Comment: save occasionally
|
Size: 3585
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 14: | Line 14: |
Dapper will be supported for five years, which makes it a great thing for vendors that which 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. | Dapper will be supported for five years, which makes it a great thing for vendors who 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. |
Line 17: | Line 17: |
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, include 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. |
|
Line 44: | Line 46: |
== Outstanding issues == Do we support the whole thing for five years, or do we try to split out a server api from desktop api stuff? There are interesting questions about kernal ABI compatability changes over security releases. Sometimes the ABI change is required. |
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. |
Line 53: | Line 50: |
Dapper Standards Base comes out to the fact that ISV's will not certify on an extra "compat" repository. Users can usually just make things work by editing their repositories to get "backwards compatability" by adding Dapper to their repository list. So, even if this isn't much work it does not generate anything significant that is worth doing. |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/foo
Created: Date(2005-11-04T20:47:54Z) by MarkRamm
Contributors: MarkRamm
Packages affected:
Summary
Any attempt to make a "Dapper Standards Base" is likely doomed to the same failures that the "Linux Standards Base" have had. The need for a system against which people can certify and can also make derivatives is key to the success of Ubuntu. This specification provides a middle road that balances these two needs.
Rationale
Dapper will be supported for five years, which makes it a great thing for vendors who 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.
However, 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, include 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 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 GPLd 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. A branded derivative MUST NOT remove or alter any packages that are installed by default with ubuntu-minimal, ubuntu-standard, ubuntu-desktop, or linux-*. The exception to this is that a branded derivative MAY replace the contents of ubuntu-desktop and ubuntu-artwork.
An Ubuntu derivative MAY installation 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.
BoF agenda and discussion
Oracle FAQ about linux: http://www.oracle.com/technology/tech/linux/htdocs/oracleonlinux_faq.html
DapperStandardsBase (last edited 2008-08-06 16:17:15 by localhost)