Currently the system-upgrade plugin downloads all packages and the waits for a reboot to install them.
With thousands of packages and each needing the install, verify and clean cycles, this can take a while, making the machine unavailable while it's doing that.
While I have done "in place" (i.e. {urpmi|apt-get|yum|dnf|etc.} upgrade while the system runs) for decades, I won't debate the reasoning for wanting to do the upgrades in a minimal, quiescent system, achieved through a reboot the way the system-upgrade plugin does.
I want to suggest an alternative to attaining that quiescent state however. On systems where the filesystem(s) are build on LVM, or where filesystems supporting bootable, writable snapshots (forking), the upgrade could be done in a snapshot, which is then configured to boot when done and a system reboot is done then. Since the full upgrade was done in the snapshot, the reboot is only as long as it takes to reboot the system.
Once rebooted on the snapshot, the user can decide to archive the origin, delete it, etc.
This would not be unlike what I actually currently do before I do an upgrade which is to take an LVM snapshot of my /, /usr, /var, and /opt filesystems. In such a case where I am unhappy with the upgraded system, I can easily fall back to my pre-upgrade state by reconfiguring my system to boot from the snapshots (i.e. point grub at the / snapshot and edit the /etc/fstab in the / snapshot to mount the /usr, /var, and /opt snapshots) and rebooting again.
The system-upgrade plugin could actually formalize this being able to fall-back to the previous system by doing all of the above, and adding an entry to the grub menu for the pre-upgraded system.
Currently the system-upgrade plugin downloads all packages and the waits for a reboot to install them.
With thousands of packages and each needing the install, verify and clean cycles, this can take a while, making the machine unavailable while it's doing that.
While I have done "in place" (i.e. {
urpmi|apt-get|yum|dnf|etc.} upgrade while the system runs) for decades, I won't debate the reasoning for wanting to do the upgrades in a minimal, quiescent system, achieved through a reboot the way the system-upgrade plugin does.I want to suggest an alternative to attaining that quiescent state however. On systems where the filesystem(s) are build on LVM, or where filesystems supporting bootable, writable snapshots (forking), the upgrade could be done in a snapshot, which is then configured to boot when done and a system reboot is done then. Since the full upgrade was done in the snapshot, the reboot is only as long as it takes to reboot the system.
Once rebooted on the snapshot, the user can decide to archive the origin, delete it, etc.
This would not be unlike what I actually currently do before I do an upgrade which is to take an LVM snapshot of my
/,/usr,/var, and/optfilesystems. In such a case where I am unhappy with the upgraded system, I can easily fall back to my pre-upgrade state by reconfiguring my system to boot from the snapshots (i.e. point grub at the/snapshot and edit the/etc/fstabin the/snapshot to mount the/usr,/var, and/optsnapshots) and rebooting again.The
system-upgradeplugin could actually formalize this being able to fall-back to the previous system by doing all of the above, and adding an entry to the grub menu for the pre-upgraded system.