Bug 1609824
| Summary: | [rfe] dnf should be able to deal with "low space vs. massive update" more vigorously, splitting the whole set into self-contained dynamically-scoped batches | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan Pokorný [poki] <jpokorny> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | dmach, mblaha, mkolman, nicolas.mailhot, packaging-team-maint, rpm-software-management, samuel-rhbugs, vmukhame |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-24 10:59:15 UTC | 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: | |||
Note that first, easy step would be teaching dnf to split the transaction containing both updates/additions and removals that cannot influence the former (may happen easily once --allowerasing and some leaf packages previously brought indirectly through dependencies are not required anymore, cf. libreoffice update + libreoffice-gtk2 removal) into two transaction: - first, proceed with whatever removals that are safe to perform independently - then, proceed with updates/additions Apparently, only when there's a disk space conflict detected. *** This bug has been marked as a duplicate of bug 1032541 *** |
The current all-or-nothing logic seems rather unfortunate provided that space-occupied-prior-to-update matches approximately space-occupied-after-upgrade, and the only thing that's a temporary(!) overhead is the interim storage of the packages themselves prior to installing them. It seems that the location of where the temporary RPM packages get stored prior to being installed is not configurable, and (not sure) if it happens to be somewhere under /var/cache/dnf, mounting that path as tmpfs (or hardlinking) is not very convenient nor necessarily the right thing to do. But it means that when there's a massive update, for instance with Rawhide + mass rebuild, there can easily be 2+ GiB of packages to download and store aside for a bit, which may be something the mounting scheme for the base system may not be very ready for. It appears, though, as if the solution is simple and akin to how the user would solve the space issue by hand: 1. pick "the right subset of packages to update" (in transitive closure of the presumably versioned dependencies) 2. update such subset, assuming no storage limit will be hit (when that happens, downscale the circle of packages-per-batch, until e.g. the limit of the smallest "atomically" installable package set is hit -- raise a "not enough space" flag then ... and only then) 3. just updated set consumed from the overall items, meaning less packages to continue with from 1., until all packages get updated eventually (and if not, it shall not break the system at least, since the dependencies will still be satisfied after each separate batch round) This wouldn't change the overall update scheme that I think is in place: download all (in a limited parallel way), then update all (serially), where "all" refers to arbitrary subset of system-wide packages If the transaction/rollback capabilities of dnf & rpm are strong enough, I think the other solution would be to allow for an opt-in mode to download and install the package as a single, reversible step, so in the extreme, there could be just a single temporary (overhead) RPM package ever present somewhere in the filesystem.