Bug 1032541

Summary: [rfe] splitting transactions under certain conditions to harden installs/upgrades
Product: [Fedora] Fedora Reporter: Miroslav Suchý <msuchy>
Component: dnfAssignee: rpm-software-management
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: low    
Version: rawhideCC: admiller, anaconda-maint-list, fedoraproject, jmracek, jzeleny, mkolman, mrmazda, ngompa13, rcyriac, robatino, rpm-software-management, samuel-rhbugs
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1665453, 1304261    

Description Miroslav Suchý 2013-11-20 11:24:08 UTC
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]

Comment 1 Ales Kozumplik 2013-11-20 13:07:58 UTC
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.

Comment 3 Ales Kozumplik 2014-09-19 09:37:14 UTC
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.

Comment 4 Honza Silhan 2014-11-24 19:50:25 UTC
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.

Comment 5 Miroslav Suchý 2014-11-25 00:43:54 UTC
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.

Comment 6 Honza Silhan 2015-07-20 09:11:01 UTC
This is really hardly to implement feature requiring the big design change in DNF.

Comment 7 Felix Miata 2016-02-10 09:08:32 UTC
(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.

Comment 8 Peter Robinson 2016-02-10 10:27:41 UTC
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

Comment 9 Fedora Admin XMLRPC Client 2016-07-08 09:26:02 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Igor Gnatenko 2016-08-12 15:45:27 UTC
This is needed.

http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000397.html

Comment 11 Neal Gompa 2017-09-16 22:24:37 UTC
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.

Comment 12 Nicolas Mailhot 2018-03-17 15:24:09 UTC
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

Comment 13 Jaroslav Mracek 2018-06-15 07:20:23 UTC
So far the issue is not on priority list.

Comment 14 Daniel Mach 2019-07-24 10:59:15 UTC
*** Bug 1609824 has been marked as a duplicate of this bug. ***