OemIso
|
⇤ ← Revision 1 as of 2009-11-19 23:00:17
Size: 4290
Comment: dump
|
Size: 4317
Comment: draft
|
| 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 20: | Line 20: |
| 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 32: |
| == 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 36: |
| You can have subsections that better describe specific parts of the issue. | === oem-config dependencies === |
| Line 30: | Line 38: |
| == Implementation == | oem-config needs to be able to install extra packages from the CD pool, e.g. language packs. |
| Line 32: | Line 40: |
| 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 42: |
| === 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 44: |
| Should cover changes required to the UI, or specific UI that is required to implement this | === Customisation tool === |
| Line 38: | Line 46: |
| === 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 54: |
| == Unresolved issues == | == Future work == |
| Line 57: | Line 56: |
| 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. |
Launchpad Entry: foundations-lucid-oem-dvd-iso
Created:
Contributors: ColinWatson, EvanDandrea, JeroneYoung, MarioLimonciello
Packages affected: new tool
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
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.
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.
FoundationsTeam/OemIso (last edited 2009-11-26 15:09:48 by 82-69-40-219)