I very often operate in virtual machines where I have very limited disk space. And something like 1.5 GB of free space in /. And very often I hit something like this during upgrade: .... Total download size: 1.2 GB So I need 1.6 GB to download all rpm files needed in transaction. But then I need several hundreds of MB to keep old files, because old files are deleted at very end of transaction. And this together is more space then I have available. So I'm forced to do something like: yum upgrade a* yum upgrade b* yum upgrade kernel* and then finaly yum upgrade It would be nice if dnf can offer to split transaction into several independent transactions. Something like: Total download size: 1.2 GB ... Transaction check. You need 1.9 GB, but only 1.5 GB are available. I can do upgrade in two independent transactions. Do you agree? [Y/n]
Hi, thanks for the report, we in fact have something like this planned because of Anaconda. The way this is going to work is that if less than some critical needed amount of memory is available then DNF switches to installing packages one by one.
Giving this (stil valid) issue up for now: doing this properly will require moving to a new, refactored and more flexible RPM backend in DNF and there is currently nobody working on it now. The discussion usually involves plans of improving/updating the current RPM Python API.
Do you still need behavior from comment 1, Anaconda guys? The original request could be solved by using flexible space in VM or dnf-automatic for smaller regular updates. There's not a big chance to make it happen soon if no more people wanted it.
Well dnf-automatic will not help you when you have cloud image, spin up new VM and you will do first dnf-upgrade. Very small cloud instances have 2 or 3 GB for root partition with 70% utilization. And that first upgrade will require 1GB which does not fit.
This is really hardly to implement feature requiring the big design change in DNF.
(In reply to Jan Silhan from comment #6) > This is really hardly to implement feature requiring the big design change > in DNF. That may be, but urpmi has been doing it for years by default, as zypper has had an option to do since long before dnf existed.
In the move over to using live-media-creator for creating live CDs, and hence dnf, we're seeing this is rel-eng related tasks where in some cases we've had to increase the disk size from 10gb to 14gb (and increase of 40%) to get the compose to complete. https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=91a99a0635562071a472c13501921cfbdd6a5f31
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is needed. http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000397.html
Can we see some movement on this? It would be great if this could be implemented, as it would help with working around three major crazy cases: 1. Not enough disk space to install the full transaction. DNF already knows whether the transaction is installable, and can error out when it's not possible to install due to lack of space. It'd be even better if DNF could re-resolve to split the transaction up so that it can be done with less than the ideal amount of free disk space. 2. Dealing with shell script %pretrans scriptlets. In both Zypper and urpmi, when shell script %pretrans are detected in initial chroot setup, the transaction is split such that the requested shell interpreter can be installed before going through the transaction containing the rpm with the shell script %pretrans. 3. Dealing with upgrades that contain rpm and dnf in the transaction. In urpmi, when rpm or urpmi is detected in the transaction, those pieces are upgraded first, and then urpmi is restarted and the transaction is automatically resumed, allowing the new code to take over for the majority of the transaction. This means that it's possible to immediately use new features in rpm and expect them to be factored into transactions, even within the same distribution release. In my opinion, it's even more valuable for distribution upgrades and rolling release upgrades, as it minimizes the chance for weird breakage as things are being upgraded.
Some of us use Fedora on chromebooks. Google in its infinite wisdom forgot to endow those with a lot of storage, it’s a continuous battle not to overflow it I so wish dnf was smart enough to split its transactions in micro updates when there’s little disk space left
So far the issue is not on priority list.
*** Bug 1609824 has been marked as a duplicate of this bug. ***