SeedManagement

Differences between revisions 43 and 44
Revision 43 as of 2007-07-30 19:18:42
Size: 15279
Editor: 87-194-29-91
Comment:
Revision 44 as of 2007-10-10 09:35:20
Size: 15306
Editor: i59F76A01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 208: Line 208:


----
CategoryProcess

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.ubuntu.com/~ubuntu-archive/seeds/, and the current output of germinate for them in http://people.ubuntu.com/~ubuntu-archive/germinate-output/gutsy/.

The actual movement of packages between main and universe is semi-automatic: a tool called [http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt 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

Seeds as of July 2007 [http://kubuntu.org/~jriddell/seeds.flw Kivio source file]

http://kubuntu.org/~jriddell/seeds.png

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.ubuntu.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:

  • absolutely stable, standard tools that we think will be around forever and we are prepared to maintain even if the whole world moves on
  • useful diagnostic tools that one can use to get the system and network up and running, and are valuable to have "always there" in case of need
  • widely applicable (in the Lowest Common Denominator sense) to every installation, desktop or server

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 [:PackageSelection:reduce the size of the system installed by debootstrap].

The raw minimal seed list for the GutsyGibbon release can be found in http://people.ubuntu.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 [PackageSelection reduce the size of the system installed by debootstrap].

The raw standard seed list for the GutsyGibbon release can be found in http://people.ubuntu.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.ubuntu.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:

  • Utilities which might be necessary in some cases in order to connect to a network
  • Common server applications

The raw Ship seed list for the GutsyGibbon release can be found in http://people.ubuntu.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.ubuntu.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.ubuntu.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 [:SimplifiedLiveCD: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 ["Arch"], 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.ubuntu.com/~ubuntu-archive/seeds/gutsy/supported

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

  • The installation CD contains the software in the Installer, Minimal, Standard, Desktop, and Ship seeds (and their dependencies)
  • The installation/live DVD contains the software in the Installer, Casper, Minimal, Standard, Desktop, Ship, Live, and Supported seeds (and their dependencies)
  • The live CD contains the software in the Casper, Minimal, Standard, Desktop, and Live seeds (and their dependencies)

Changing the Seeds

Proposals for adding new packages to the seeds should be added to the UbuntuMainInclusionQueue page; please prepare a report as described on that page and send the proposal and a link to the report to the ubuntu-devel mailing list.

The seed archives are now managed in [http://bazaar-vcs.org/ bzr]; you will need at least version 0.8. If your distribution does not have bzr 0.8, nightly snapshots are available in the bzr package at http://people.ubuntu.com/~jbailey/snapshot/bzr/.

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:

  • If you are in the [https://launchpad.net/~ubuntu-core-dev ubuntu-core-dev team] and have an SSH key registered in Launchpad, install the python2.4-paramiko package (from your distribution, or from the [http://people.ubuntu.com/~jbailey/snapshot/bzr/ nightly snapshot archive], and, replacing $USER with your Launchpad user ID:

    bzr checkout sftp://$USER@bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy
  • If you aren't in the [https://launchpad.net/~ubuntu-core-dev ubuntu-core-dev team], then a public but read-only mirror is here:

    bzr checkout --lightweight http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy

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 [http://bazaar-vcs.org/SharedRepositoryTutorial#head-8cb3abac88b0c2268c7e8c8d90732f8478aa9f03 bzr shared repository tutorial] for more information on this mode of operation.

  • For the Kubuntu seeds replace ubuntu. with kubuntu. in the command above. For the Edubuntu seeds replace ubuntu. with edubuntu.. For the Xubuntu seeds replace ubuntu. with xubuntu..

  • Note that changes to the seeds do not automatically cause packages to move to a new component in the archive. See UbuntuMainInclusionQueue.

  • If any of the ubuntu-meta, kubuntu-meta, edubuntu-meta, or xubuntu-meta source packages build a metapackage for the seed you changed, run the update script in the appropriate source package and upload it (after your changes have been effected in the seeds archive; you will need to wait about 20 minutes for these changes to propagate to the public mirror; TODO (cjwatson) don't bother trying this for edgy yet).

  • If you have an older branch (whether locally-modified or not) of any of the seeds made before 2006-05-18 or with a version of bzr earlier than 0.8, then please upgrade to bzr 0.8 and run 'bzr upgrade' in that branch, to convert to the newer "knit" branch format. If you do not do this, then, while everything should still work, pulling and pushing will be very slow.

UDU Notes

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 plusses of this method are:

  • Much less coding resource needed from the Launchpad team in the short term (don't need to design entire DB sections and pages for editing seeds) but in the long term we're still flexible for moving to more control in launchpad
  • Ubuntu team gets their history, branching, merging, diffing, etc all for free from bazaar.
  • Ubuntu team continue to get their direct low-level control of how seeds affect the components.
  • Ubuntu team have slightly less to learn to move to Launchpad in the initial case.

The minuses of this method are:

  • Less direct control in Launchpad
  • Launchpad has to have access to the supermirror
  • Direct pybaz dependency will be introduced.

The launchpad stuff:

  • Launchpad gains a concept called a 'Flavour' which for now has an arch branch in a text field. Later we can always key seed tables off this table.
  • Flavours do not inherit within the launchpad because that'd be too confusing for the seed management people. They get inheritance by virtue of bazaar's branching and merging, ancestry etc and this seems a desirable level for them.


CategoryProcess

SeedManagement (last edited 2022-04-06 17:52:01 by schopin)