Definition

Seeds are the lists of packages we want to include in the distribution. We have seven primary seeds, minimal, boot, standard, desktop, ship, live, and supported, that define what goes into the archive's main component. The minimal, boot, standard, desktop, and either ship or live seeds go onto our CDs and the supported packages are available from the FTP site.

Seeding a package pulls all of its dependencies into the appropriate part of the archive and ensures everything needed to build that package is at least placed in supported.

You can view the current seeds in http://people.canonical.com/~ubuntu-archive/seeds/, and the current output of germinate for them in http://people.canonical.com/~ubuntu-archive/germinate-output/.

The actual movement of packages between main and universe is semi-automatic: a tool called component-mismatches produces a report on what should be promoted or demoted according to the seeds, which the archive administrators review by hand and process.

Graph

Germinate was modified so that it produces a structure.dot file which can be used to produce a graph of the seeds structure using graphviz. This can be useful to figure how the seed are overall linked:

Descriptions of Seeds

Boot

The boot seed lists default kernels and boot loaders required for each processor architecture. It is kept separate from the minimal seed for technical reasons, chiefly that having debootstrap install default kernels and bootloaders reduces the flexibility of the installer to choose alternatives.

In Ubuntu 5.10 and earlier, the boot seed was part of the minimal seed.

The raw boot seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/boot

Minimal

The minimal system provides enough packages to install a basic command-line system, boot, and install more packages. It also contains any packages that should be available the first time the system boots after installation (for example, hardware detection blacklists). It does not provide X11 or any services listening on any non-localhost ports.

Packages in minimal should be:

A "minimal" system is not expected to be useful for any particular purpose; it's simply there for bootstrapping of more interesting systems.

In Ubuntu 5.04 and earlier, the minimal and standard seeds were part of a single base seed. They were separated in order to reduce the size of the system installed by debootstrap.

The raw minimal seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/minimal

Standard

The standard system provides a solid foundation for a desktop or server without providing X11 or any services listening on any non-localhost ports. This seed package list, once the complete dependency set has been added, provides that system.

The criteria for packages in standard are similar to those for packages in minimal, but we concentrate more on the Greatest Common Factor than on the Lowest Common Denominator: the standard system includes packages that make up a traditional comfortable UNIX system, a variety of networking clients and tools, advanced filesystem support, and various diagnostic utilities.

A "standard" system is not expected to be useful for any particular purpose. It's simply the minimal working system that we will support. It should be a platform that one can quickly get working, and on top of which one can construct a useful collection of services. Typically, servers would start out life as a "standard" system, and the system administrator would then add specific services and packages as needed.

In Ubuntu 5.04 and earlier, the minimal and standard seeds were part of a single base seed. They were separated in order to reduce the size of the system installed by debootstrap.

The raw standard seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/standard

Desktop

The Desktop seed, minimally summarised, ought to be a checklist of desktop features that would appeal to a user or procurer. Our default Desktop install should include every single package mentioned in the Desktop seed. Thus, the seed should be as simple as possible without being too simple, and be directly focused on solving desktop problems.

[ One of the valuable design choices in Debian is that if you install a daemon, it is assumed that you intend to use it. If you don't want to run it, don't install it. Requiring that a daemon be installed but not wanting to run it is a rarely-by-few use case, so Debian doesn't optimise for it. Rightly so. We ought to look at our Desktop seed in a similar light. If we put it on the list, it should be installed. If we install it, assume that it will be used. In some cases, this will be "running by default", but in most cases on the desktop, it just means "available or visible by default". ]

We should not confuse the Desktop seed with "what's on the CD", because we can always fill the remaining space on the CD with high priority items. Similarly, we should not put important things that are independent of our desktop solution in the Desktop seed, as this will adversely affect our focus. Major distro features that are not Desktop oriented should have their own sections on the Supported seed page.

The raw desktop seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/desktop

Ship

Packages which will be included on the CD for convenience, but are not part of the default set of packages to install. Common examples include:

The raw Ship seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/ship

Live

Software which will be installed on the Ubuntu LiveCD, in addition to the default desktop set.

The raw Live seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/live

Installer

The installer seed tracks packages which are part of the installer as used on the install CD.

The raw Installer seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/installer

Casper

The casper seed tracks packages which are part of the installer subset used on the live CD. It is no longer used as of DapperDrake, following the introduction of the new simplified live CD.

Supported

The supported system provides functionality not included by the base or desktop systems but which meets the following criteria:

  1. it is very widely used, people are committed to it.
  2. it is not architecturally insecure, it is thus easy for us to provide security fixes and updates.

This list would include popular servers other than the ones we include in a Base or Desktop install; additional desktop software; and a build environment. It is never expected that someone would install the entire Supported list of packages, they would choose specific packages that provide specific needed functionality.

This list is all the extra packages we think need to be supported in our distro. We will accept contributions of additional packages into this list, if they:

  1. have an external maintainer who agrees to maintain them to our standard, in Bzr, using Soyuz

  2. pass a one-time security review from MartinPitt and agree to be responsive to him on SecurityPage issues

Some packages in this list will also ship on the CD, subject to the amount of space we have on the CD. They would typically be cached on the installed hard drive for rapid installation without the CD. All of these packages will be available in the online archive of packages.

The raw Supported seed list for the GutsyGibbon release can be found in http://people.canonical.com/~ubuntu-archive/seeds/gutsy/supported

The supported seed has been split during the Intrepid cycle, so that the supported seed is split functionally and allows people to distinguish between server and desktop packages. This was particularly needed in order to know if the three-year or five-year maintenance period would apply for a given package. A good way to gain an understanding of it is to take a look at the graphs.

supported-desktop

Should not contain anything; it aggregates the more specific desktop-related seeds.

supported-desktop-extra

Packages that get a additional support for 3y on a LTS.

supported-server

Should not contain anything; it aggregates the more specific server-related seeds.

supported-hardware-desktop

Hardware-related packages used on desktops only.

supported-hardware-common

Hardware-related packages that are used both on desktop and server.

supported-installer-desktop

Installer-related packages used for desktop installations only.

supported-installer-common

Installer-related packages that are used both on desktop and server.

supported-network-common

Network-related packages that are used both on desktop and server.

supported-sysadmin-desktop

System administration packages that are used both on desktop and server.

supported-sysadmin-common

System administration packages that are used both on desktop and server.

supported-development

Development packages that are used both on desktop and server.

supported-misc-servers

Miscellaneous server-only packages.

supported-kernel

Kernel packages that are used both on desktop and server.

Extra

Binary packages which are built by a supported source package, but not supported themselves, are automatically added to a special "extra" list.

How the Seeds are Used

Germinate

The seeds are read by a program called Germinate, which resolves the dependencies of packages in the seed lists. By adding additional packages to satisfy these dependencies, the final package lists are produced.

CD builds

Changing the Seeds

If seeding the package would mean that it had to be in main and it is not currently then you should go through the MainInclusionProcess for the package first. If the package is in main, or seeding the package wouldn't require it to be in main (e.g. seeding for a CD built from universe) then you can skip this step.

In general, we recommend the use of bound branches (checkouts) for working with the seeds. The instructions below assume this model. If you have other requirements, we assume that you know what to do!

To get a checked-out copy of the seeds that you can edit:

bzr checkout lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.oneiric

Make sure to set an appropriate user id in ~/.bazaar/bazaar.conf, like this:

[DEFAULT]
email=Colin Watson <colin.watson@canonical.com>

To update a checkout, use bzr update. If you're merging from other seed branches, you should normally do this first.

To commit:

bzr commit -m 'commit message'

If either the commit fails locally or bzr fails to push the change to the remote branch on bazaar.launchpad.net, then the whole commit will fail. If the problem is simply that somebody else committed just before you, then you should bzr update. If you are offline for a short period, you can use bzr commit --local to commit the change just to your local branch, or if you are offline for a longer period, you can use bzr unbind to disconnect your local branch from the remote branch; in either case, you can use bzr bind when you come back online to reconnect to the remote branch and push up your local changes.

See the bzr shared repository tutorial for more information on this mode of operation.

Debugging seed problems

Why does package X get pulled onto the CD (or into the archive)?

All the logs necessary to answer this kind of question are available, but they do take some interpretation, and sometimes you need to run germinate locally if you don't have access to all its output. Let's take a worked example, of investigating why exim4-base and friends landed on the Ubuntu alternate install CD (this happened on 2009-01-15):

Maintenance Period

Maintained means that the team commits to providing security updates for the packages that are defined in the seed and whatever dependencies are necessary to make them work.

The exact manifest are release specific and can found at the ReleaseManifest page of the release in question (e.g. for 10.04 LTS at LucidLynx/ReleaseManifest).

Canonical provides free maintenance for Ubuntu products as follows:

The Packages file contains the Supported field, as generated by Soyuz.

The content of main is defined as the union of the seeds: ubuntu.all, kubuntu.all, edubuntu.all, netbook.all. If that changes the code in lp:launchpad cronscripts/publishing/maintenance-check.py needs updating.

UDU Notes

(These are probably obsolete.)

Status

Braindump notes

Launchpad does not manage seeds within its database. Instead we have an arch branch on the supermirror and tell the Launchpad about the branch. We then have a tool which takes germinate output, interacts with launchpad (E.g. over XMLRPC) and does the component changes. We can also integrate that into the appservers so you can click a button, launchpad will check out the branch from the supermirror, germinate and let you manipulate things that way.

The pluses of this method are:

The minuses of this method are:

The launchpad stuff:


CategoryProcess

SeedManagement (last edited 2012-11-20 22:33:31 by brian-murray)