OemIso

Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2009-11-19 23:00:17
Size: 4290
Editor: 63
Comment: dump
Revision 3 as of 2009-11-26 15:09:48
Size: 4102
Editor: 82-69-40-219
Comment: relnode
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''':  * '''Contributors''': ColinWatson, EvanDandrea, JeroneYoung, MarioLimonciello
Line 10: Line 10:
This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. Create a CD image optimised for OEM deployment. In Dell's case, it should include what is on the standard CD image, all language packs, proprietary drivers, kernel & headers (PAE kernel & headers also for i386), and Ubiquity. Other OEMs may have different requirements.
Line 14: Line 14:
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.
Ubuntu now includes a simple customisation tool that can be used by OEMs to construct modified CD images appropriate for their needs.
Line 20: Line 18:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. Some OEMs have very tight margins on their factory deployments: the speed of installation has a direct effect on how fast they can churn out systems. The size of the installation image often makes a considerable difference to installation speed, and the Ubuntu DVD is typically much slower than the Ubuntu desktop CD. (In particular, Dell's recovery partition is created by copying the installation image.)

On the other hand, we don't want to have to try to figure out what's suitable for all OEMs, nor do we really want to centrally maintain and test another image for each of several flavours. As such, a tool to generate appropriate images seems to be the best option.

== Scope ==

To allow us to squeeze this work into Lucid, we'll be keeping the scope quite tightly under control. In particular, at this point we will not permit customising the live filesystem, but only the package pool on the CD. The user will need to supply an existing image with an appropriate live filesystem.

Canonical's OEM Services team may be able to offer QA services for individual output images. That is out of scope for this development project, but is of course in scope for the wider organisational work.
Line 24: Line 30:
== Assumptions ==  * Mario wants a CD image containing (in addition to the Ubuntu desktop CD) all language packs, fglrx, nvidia, wl, and linux-generic-pae, since that is what's appropriate for his deployed systems. He only cares about i386 for the moment, but will switch to amd64 once 64-bit Flash is stable.
Line 28: Line 34:
You can have subsections that better describe specific parts of the issue. === oem-config dependencies ===
Line 30: Line 36:
== Implementation == oem-config needs to be able to install extra packages from the CD pool, e.g. language packs.
Line 32: Line 38:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: We will add additional preseedable templates to specify the pool location (default: just follow `/etc/apt/sources.list`) and for an arbitrary early shell command in `oem-config` (no default; in this case, could be used to mount the recovery partition where the pool may reside).
Line 34: Line 40:
=== UI Changes === (See the [[http://netbook-remix.archive.canonical.com/updates/pool/public/l/language-installer/|language-installer]] tool written by OEM Services, although we may prefer to reuse existing code from `ubiquity` since it's already in the same source package.)
Line 36: Line 42:
Should cover changes required to the UI, or specific UI that is required to implement this === Customisation tool ===
Line 38: Line 44:
=== Code Changes ===

Code changes should include an overview of what needs to change, and in some cases even the specific details.

=== Migration ===

Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.
The customisation tool will take at least an existing image, a list of package names or patterns to add to the pool, and optionally a list of package names or patterns to remove from the pool. It will fetch these packages from the archive and add them to the pool, regenerate Packages and Release files (without GPG-signing), and build the resulting tree into a new image. Constrained to this modest level of complexity, this should be reasonably straightforward.
Line 55: Line 52:
== Unresolved issues == == Future work ==
Line 57: Line 54:
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

== BoF agenda and discussion ==

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

{{{
== Rationale ==

Dell tends to purge most of the pool from the DVD before installing, to just what's needed by Ubiquity installs
Excessive DVD size causes extra factory burn time, because it's copied to the recovery partition
cdimage is pretty close to its tolerances (both in terms of physical disk space and in terms of platform QA capacity to validate ISOs around release time), and another matrix column is difficult

== Design ==

Maintain a tool to perform a required transformation, and pass the result through OEM Services?
Advantage of tool approach is that it provides more flexibility for different customer requirements, although it does involve more setup and less centralisation
Future work: (web?) front-end to permit arbitrary package selection (see also previous discussions around customisation tools, cf. Fedora's Reconstructor etc.)

Seed for additional contents, containing (in Dell's case):
 * language-pack-*
 * language-support-* (or equivalent)
 * fglrx
 * nvidia
 * wl
 * linux-generic-pae
 * oem-config-gtk

Dell need i386 only; will switch to amd64 once 64-bit Flash is stable

Depends on work in oem-config to install packages from pool
 * requires additional preseed to specify pool location (default: whatever sources.list says)
 * requires additional preseed for early command (mount recovery partition, where pool resides)
 * OEM Services has a `language-installer` tool for this, although we may prefer to use code from `ubiquity` to integrate with `python-apt`; requires further investigation to see what code can be reused
  * http://netbook-remix.archive.canonical.com/updates/pool/public/l/language-installer/
}}}
A web (or other) front-end to permit arbitrary package selection. See also previous discussions around customisation tools, cf. Fedora's Reconstructor etc.

Summary

Create a CD image optimised for OEM deployment. In Dell's case, it should include what is on the standard CD image, all language packs, proprietary drivers, kernel & headers (PAE kernel & headers also for i386), and Ubiquity. Other OEMs may have different requirements.

Release Note

Ubuntu now includes a simple customisation tool that can be used by OEMs to construct modified CD images appropriate for their needs.

Rationale

Some OEMs have very tight margins on their factory deployments: the speed of installation has a direct effect on how fast they can churn out systems. The size of the installation image often makes a considerable difference to installation speed, and the Ubuntu DVD is typically much slower than the Ubuntu desktop CD. (In particular, Dell's recovery partition is created by copying the installation image.)

On the other hand, we don't want to have to try to figure out what's suitable for all OEMs, nor do we really want to centrally maintain and test another image for each of several flavours. As such, a tool to generate appropriate images seems to be the best option.

Scope

To allow us to squeeze this work into Lucid, we'll be keeping the scope quite tightly under control. In particular, at this point we will not permit customising the live filesystem, but only the package pool on the CD. The user will need to supply an existing image with an appropriate live filesystem.

Canonical's OEM Services team may be able to offer QA services for individual output images. That is out of scope for this development project, but is of course in scope for the wider organisational work.

User stories

  • Mario wants a CD image containing (in addition to the Ubuntu desktop CD) all language packs, fglrx, nvidia, wl, and linux-generic-pae, since that is what's appropriate for his deployed systems. He only cares about i386 for the moment, but will switch to amd64 once 64-bit Flash is stable.

Design

oem-config dependencies

oem-config needs to be able to install extra packages from the CD pool, e.g. language packs.

We will add additional preseedable templates to specify the pool location (default: just follow /etc/apt/sources.list) and for an arbitrary early shell command in oem-config (no default; in this case, could be used to mount the recovery partition where the pool may reside).

(See the language-installer tool written by OEM Services, although we may prefer to reuse existing code from ubiquity since it's already in the same source package.)

Customisation tool

The customisation tool will take at least an existing image, a list of package names or patterns to add to the pool, and optionally a list of package names or patterns to remove from the pool. It will fetch these packages from the archive and add them to the pool, regenerate Packages and Release files (without GPG-signing), and build the resulting tree into a new image. Constrained to this modest level of complexity, this should be reasonably straightforward.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Future work

A web (or other) front-end to permit arbitrary package selection. See also previous discussions around customisation tools, cf. Fedora's Reconstructor etc.


CategorySpec

FoundationsTeam/OemIso (last edited 2009-11-26 15:09:48 by 82-69-40-219)