System-critical package management
The lack of any system of recognition for packages that are critical to system operation impedes the reliability of Debian-based systems. For example, a reboot during a background package upgrade process on critical system packages unbeknownst to the user may result in the system unable to boot as expected, with little readily-available feedback to the user as to the cause.
Other operating systems like Windows and MacOS manage this by updating system-critical components separately from user-land during shutdown, while clearly giving user-feedback that critical updates are taking place, and that for example the system should not be turned off.
The way in which DPKG deals with packages is preferable in many ways as upgrades are almost entirely made in standard user-land, and is largely transparent (for example, an upgrade will not automatically begin during shutdown without any indication to user that this will take place). It also of course means that Debian systems are highly configurable.
A potential middle-ground solution to this is to allow packages to be marked as "system-critical" to DPKG by external system components - for example a standard desktop Ubuntu system might mark the Gnome Display Manager, Networking drivers, and others in this way during installation. These system-critical packages could then be protected by DPKG in the following ways:
- They are automatically reverted to a known good state on upgrade failure (e.g. previous version)
- They cannot be removed without being unmarked as "system-critical"
- The system could check during every shutdown that system-critical packages are in a consistent state, reverting to a known good state if not
I am interested in knowing the communities' thoughts on this, and if these ideas have any merit to them.
- Peter Warrington
Reply to: