CDRomBasedUpgradesSpec

Differences between revisions 1 and 14 (spanning 13 versions)
Revision 1 as of 2006-06-08 12:11:11
Size: 984
Editor: p54A6673E
Comment:
Revision 14 as of 2006-06-29 13:01:53
Size: 6451
Editor: p54A6718A
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/xdeltas  * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/cdrom-based-dist-upgrades
Line 6: Line 6:
 * '''Packages affected''':  * '''Packages affected''': update-manager
Line 18: Line 18:
 * John has only got a slow dial up connection (modem) to the internet. Upgrading to dapper would require him to download around an half gbyte of packages - this would take about 20 hours of downloading. He would benefit by a descreased download size.

 * Maria does very security critcal work on her computer. So she decided to not connect it to the internet at all. All packages for an upgrade have to be provided on a cd or usb stick.
Line 19: Line 23:

The dist-upgrader code (part of the update-manager bzr) is affected by this spec.
Line 24: Line 30:
The CD needs to contain some meta-information like what version it is, what it can upgrade and the actual code to do the upgrade (similar to the meta-release file on http://changelogs.ubuntu.com/meta-release). The tools should basicly do the same things as the "normal" dist-upgrader (rewrite sources.list, upgrading, detecting cruft, cleaning up etc).

The difference between the "normal" dist-upgrader mode should be that it asks if it should use the network (if there are any network sources in the sources.list) and that it should warn about the fact that for network usage a lot of packages need to be installed. If no network is available the sources.list should still be rewritten, but no "cache.update()" should be run. We need to make sure that the cdrom source is disabled/removed if the user cancels the upgrade otherwiese the user will see scary messages from update-manager about updates on the CD. The user should be able to cancel if the download for him is too much. We should try to estimate the amount of time it will take to download the packages not found upgradable on the CD. This can be done by showing how long it will take with a typical modem/isdn line (56k modem) and a "normal" DSL line (1Mb).

We may consider hooking this with some simple "generate a download wget script/import downloaded debs" button for the download to do the actuall package download on a faster conntected machine. If the OfflineUpdatesSpec is ready by then we probably want to reuse as much from it as possible. It might be worth consider to have a "start downloading" option that starts and stores the packages to continue later.

The update-notifer code to detect Ubuntu CDs should be reused for the detection. It is currently able to detect CDs that look like ubuntu CDs. To make the approach more flexible and robust it will callout to a python script that analyses the CD and take the appropriate action based on if it is a CD with packages, a dist-upgradable CD, a language-pack addon CD or a CD created with the offline-udpate tool.

The dist-upgrader should check if there is a updated version on the network if network is available (to make it possible to fix bugs after release too).

We should also show how long it will take for various network connection speed to download the stuff needed from the net (like "this will take 2h for a 56k modem, 10min on 2Mbit broadband). Or even include a speed-test to figure the speed to the server out yourself.
Line 26: Line 44:
=== Code ===

=== Data preservation and migration ===
No code for this special case has been written yet.
Line 32: Line 48:
 * The main problem are custom repositories and packages that are installed from the universe or multiverse components. So a single CD with only main won't be sufficient in the most cases. There is little we can do about this, but we should try to make sure that our OfflineUpdate tools support this use-case as good as possible.

 * The new desktop-cd has no deb packages on it aynmore so this works for the alternative-install-cd only. This makes this feature less important, but it should still be provided.
 
Line 33: Line 53:

Julien Hémono - Isn't it done by the alternate CD ? :
{{{Alternate install CD

The alternate install CD allows you to perform certain specialist installations of Ubuntu. It provides for the following situations:

    * creating pre-configured OEM systems;
    * setting up automated deployments;
    ---> * upgrading from older installations without network access;
    * LVM and/or RAID partitioning;
    * installing GRUB to a location other than the Master Boot Record;
    * installs on systems with less than about 192MB of RAM.
}}}
 * Sort of, but only if you upgrade by hand. This specification is about reducing the requirement for manual work. (The main point of the note you saw is to emphasise that the desktop CD ''cannot'' currently be used for upgrades.) -- ColinWatson

 * We missed one important point in yesterdays BOF. Even external CD-Creators are not allowed to ship e.g. patented software, e.g. MP3 Codecs (or they pay patent fees). So, there is always an issue with our official universe/multiverse repositories, even when they are not produced by Ubuntu/Canonical, but from third party CD ISO Shops. -- StephanHermann

 * I disagree that the new desktop cd makes the need for CD-based upgrades less important. It makes it more troublesome to provide for CD-based upgrades but they are just as important as they ever were. --IanJackson

 * Maybe a gui-based tool called aptoncd can help. It is under development, and it's specs are copatibles with CDRomBasedUpgradesSpec , because what the tool do is a CD/DVD with all packages of selected repositories (main, restricted, universe or multiverse) and can make a CD/DVD with downloaded packages of apt-cache creating a removable repository that can be used in a lot of machines to make [dist]upgrades. To know more about the project, please visit [http://www.cypherbios.org/aptoncd/ APTonCD main page]. --CypherBios

Summary

The dist-upgrader that was introduced for breezy->dapper upgrades relies heavily on being on a (fast) network. A process for (dist)upgrades without network should be added as well.

Rationale

Not everyone has broadband network or cheap internet. We need to find a way to support dist-upgrades (perferable via the dist-ugprader mechanism) via cdroms.

Use cases

  • John has only got a slow dial up connection (modem) to the internet. Upgrading to dapper would require him to download around an half gbyte of packages - this would take about 20 hours of downloading. He would benefit by a descreased download size.
  • Maria does very security critcal work on her computer. So she decided to not connect it to the internet at all. All packages for an upgrade have to be provided on a cd or usb stick.

Scope

The dist-upgrader code (part of the update-manager bzr) is affected by this spec.

It should both support the case when the machine is not networked at all or when the network is avialable but slow and expensive.

Design

The CD needs to contain some meta-information like what version it is, what it can upgrade and the actual code to do the upgrade (similar to the meta-release file on http://changelogs.ubuntu.com/meta-release). The tools should basicly do the same things as the "normal" dist-upgrader (rewrite sources.list, upgrading, detecting cruft, cleaning up etc).

The difference between the "normal" dist-upgrader mode should be that it asks if it should use the network (if there are any network sources in the sources.list) and that it should warn about the fact that for network usage a lot of packages need to be installed. If no network is available the sources.list should still be rewritten, but no "cache.update()" should be run. We need to make sure that the cdrom source is disabled/removed if the user cancels the upgrade otherwiese the user will see scary messages from update-manager about updates on the CD. The user should be able to cancel if the download for him is too much. We should try to estimate the amount of time it will take to download the packages not found upgradable on the CD. This can be done by showing how long it will take with a typical modem/isdn line (56k modem) and a "normal" DSL line (1Mb).

We may consider hooking this with some simple "generate a download wget script/import downloaded debs" button for the download to do the actuall package download on a faster conntected machine. If the OfflineUpdatesSpec is ready by then we probably want to reuse as much from it as possible. It might be worth consider to have a "start downloading" option that starts and stores the packages to continue later.

The update-notifer code to detect Ubuntu CDs should be reused for the detection. It is currently able to detect CDs that look like ubuntu CDs. To make the approach more flexible and robust it will callout to a python script that analyses the CD and take the appropriate action based on if it is a CD with packages, a dist-upgradable CD, a language-pack addon CD or a CD created with the offline-udpate tool.

The dist-upgrader should check if there is a updated version on the network if network is available (to make it possible to fix bugs after release too).

We should also show how long it will take for various network connection speed to download the stuff needed from the net (like "this will take 2h for a 56k modem, 10min on 2Mbit broadband). Or even include a speed-test to figure the speed to the server out yourself.

Implementation

No code for this special case has been written yet.

Outstanding issues

  • The main problem are custom repositories and packages that are installed from the universe or multiverse components. So a single CD with only main won't be sufficient in the most cases. There is little we can do about this, but we should try to make sure that our OfflineUpdate tools support this use-case as good as possible.

  • The new desktop-cd has no deb packages on it aynmore so this works for the alternative-install-cd only. This makes this feature less important, but it should still be provided.

BoF agenda and discussion

Julien Hémono - Isn't it done by the alternate CD ? : {{{Alternate install CD

The alternate install CD allows you to perform certain specialist installations of Ubuntu. It provides for the following situations:

  • creating pre-configured OEM systems;
  • setting up automated deployments;

    ---> * upgrading from older installations without network access;

  • LVM and/or RAID partitioning;
  • installing GRUB to a location other than the Master Boot Record;
  • installs on systems with less than about 192MB of RAM.

}}}

  • Sort of, but only if you upgrade by hand. This specification is about reducing the requirement for manual work. (The main point of the note you saw is to emphasise that the desktop CD cannot currently be used for upgrades.) -- ColinWatson

  • We missed one important point in yesterdays BOF. Even external CD-Creators are not allowed to ship e.g. patented software, e.g. MP3 Codecs (or they pay patent fees). So, there is always an issue with our official universe/multiverse repositories, even when they are not produced by Ubuntu/Canonical, but from third party CD ISO Shops. -- StephanHermann

  • I disagree that the new desktop cd makes the need for CD-based upgrades less important. It makes it more troublesome to provide for CD-based upgrades but they are just as important as they ever were. --IanJackson

  • Maybe a gui-based tool called aptoncd can help. It is under development, and it's specs are copatibles with CDRomBasedUpgradesSpec , because what the tool do is a CD/DVD with all packages of selected repositories (main, restricted, universe or multiverse) and can make a CD/DVD with downloaded packages of apt-cache creating a removable repository that can be used in a lot of machines to make [dist]upgrades. To know more about the project, please visit [http://www.cypherbios.org/aptoncd/ APTonCD main page]. --CypherBios


CategorySpec

CDRomBasedUpgradesSpec (last edited 2008-08-06 17:00:16 by localhost)