On Wed, Feb 3, 2016 at 3:28 PM, Felix Miata <mrmazda@xxxxxxxxxxxxx> wrote: > I have lots of test installations using identical partition sizes for EXT3 or > EXT4 / filesystems. the filesystem space these provided is adequate on all if > running Mageia or openSUSE, but quite often not for Fedora. Working around > the inadequacy on Fedora presents problems #2 & #3. > > Problem #1: > NAICT, DNF, like Yum before it, offers no option I can recognize from its man > page to download less than all the to-be-updated/installed packages before > proceeding to install any packages. Thus it downloads (typically hundreds of > packages), cutting into available / freespace. Then it does transaction > checking before package installation begins, and after which commonly it > halts, reporting some small amount of freespace is required on the / > filesystem, space that obviously wasn't required for the installation to be > operable. By intervening updating of packages in various bunches instead, > updating, though laborious, is successful, and freespace when done is > perfectly adequate, resulting in total freespace roughly equivalent to Mageia > and openSUSE. > > Problem #2: > A way to work around problem #1 is with wildcards, e.g. > > # dnf update g* i*, kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* > > When this example is used following observance of problem #1, DNF naturally > skips downloading packages already downloaded and meeting the cmdline spec, > and silently deletes all already downloaded packages not meeting the spec, so > that when e.g. the following is run > > # dnf a* b* c* d* e* f* h* > > the cache begins empty, and it downloads the packages deleted mere minutes ago. > > Problem #3: > When running from say the /boot directory the same dnf command above: > > # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* > > dnf reports cannot install package inityada, cannot install package vmliyada, > .... It ought to be smart enough not to try to install local files that are > not installation package files (e.g., those ending in .rpm or any other type > it might understand and support). > > The reason Mageia doesn't have any of these problems is that it naturally and > by default downloads a small bunch, installs them, downloads another bunch, > installs those, etc. Similarly, openSUSE's zypper offers options to download > one, install one, download second, install second, download third, install > third, etc. (DownloadAsNeeded), and another option to do more or less as > Mageia's urpmi does (DownloadInHeaps), as alternatives to its default > (DownloadInAdvance). Updating Mageia and openSUSE typically takes 30-60 > minutes to update 600-800 packages without babysitting the cmdline, while > Fedora on these installations can take several hours between waiting on the > duplicate downloads and not looking at the screen at the right time to answer > y or input another group of packages using wildcards. > > 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. And probably a stronger warning and/or enforcement for sane root fs size to grow, at installation time. 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's even less atomic of an update than what we have now, and is the opposite of the direction Fedora wants to go in. If you check out Project Atomic or rpm-ostree, the gist is that there is no local package manager, instead you deploy trees. A whole new updated tree (containing changes from the current tree) is downloaded and installed in an atomic fashion, ie the file system tree that's currently deployed is not touched, and therefore a failed upgrade doesn't ever wreck it. There is actually a very straightforward way to get atomic updates now with Btrfs, and doing the update either in a 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. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
