From Mageia wiki
Jump to: navigation, search

Summary

Drop official support for updating certain system components on a live system and only support distribution upgrades in a tightly controlled and isolated environment (not on a "running" system).

Owner

  • Name: Colin Guthrie
  • Email: colin@mageia.org

Resources

Installer, Dracut and (possibly) packagekit (tho' not essential)

Current status

  • Targeted release: Mageia 4
  • Last updated: 2013-05-09
  • Percentage of completion: 0%

Detailed Description

During each distribution cycle, one of the biggest QA problems is ensuring that users can upgrade from one version to the next. At present we support both an installer based upgrade (i.e. boot from an installer ISO) or upgrading via mgaapplet. Both cases have problems:

  • If the ISO is a full image it may still not contain all packages which may result in some transactional problems while upgrading and may leave some old packages left behind.
  • In the case of mgaapplet upgrading, it is particularly problematic as upgrading certain system components can cause significant problems to a running system (see #9534, #9882 to name just two).

In order to solve this problem, the installer upgrade should insist on a network connection to download packages it does not contain thus avoiding such problems. For the Mageia Applet, we should stop offering to upgrade distribution and instead make users reboot into a controlled environment (possibly fully contained within the initrd or copied from the running system) that allows an upgrader to run in an offline mode that will ensure that system upgrades can be performed without worrying about whether it is going to break the running system.


Why it would be good for Mageia to include it

This approach, while a step change, will ultimately lower QA burden and avoid possible Heisenbugs resulting from the set of packages installed and the desktop environment the user is running etc.

Test case

Upgrade Mageia 3 to Mageia 4.

Software / Packages Dependencies

There is now support in systemd for an offline-updates target specifically to handle this kind of use case. We should investigate whether this fits our needs directly or if we should more tightly integrate this feature to our installer.

What could disrupt development of this new feature

TBC

Planning

TBC

Contingency

Just stick with our current setup and deal with the bugs/problems.

Release Notes

Documentation