Chris Murphy composed on 2016-02-03 15:54 (UTC-0700): > Felix Miata wrote: ... >> Does anyone here agree that each of the three would represent legitimate >> wishlist bugs, unlikely to be summarily dismissed as wontfix? > My expectation is that's a lot more work than for dnf to do a better > estimate and enforcement of free space before starting an upgrade in > the first place. Surely that would be most welcome. > And probably a stronger warning and/or enforcement > for sane root fs size to grow, at installation time. Sane for a normal user's installation differs from sane here. Recommended sizes are vastly different from what will serve the special purposes of testing specific subsets of a normal system. > I also think such a staged approach to updates increases the chances > of a wrecked installation if this sort of staged upgrade is > interrupted by a crash or power failure. It goes without saying. Nevertheless, working on UPSes with throwaways and easy to create/backup/restore little filesystems have their own advantages. I've been doing this for over a decade, experiencing many power failures here in the lightning capital of North America, subscribed to the least reliable power provider I'm aware of in any civilized country. I can't remember the last time an upgrade process on Mageia or openSUSE was ever destroyed by power failure, if it ever happended at all. I probably spend as much money on UPS batteries than I do on PC hardware. > It's even less atomic of an > update than what we have now, and is the opposite of the direction > Fedora wants to go in. > ...There is actually a very straightforward way to > get atomic updates now with Btrfs, and doing the update either in a BTRFS, nor any other filesystem type, is not something I care to include in my testing processes. > chroot or container (nspawn or docker) and a rw snapshot. The changes > happen completely out of tree, so not only is your running system not > yanked out from under it while you're working, but if it fails for any > reason the hosed fs trees can just be deleted and the update attempt > retried. If it works, update fstab and the bootloader configuration to > now boot the upgraded tree, leaving the old one intact in case the > reboot goes wrong or there's some regression. All mine are multiboot installations, so I have ample fallback and option, without any need for radical surgery on what ain't broke. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
