Bug 2100811

Summary: A yum install command success will delete the content of the previous command downloadonly destdir
Product: Red Hat Enterprise Linux 8 Reporter: adrian
Component: dnfAssignee: Jan Kolarik <jkolarik>
Status: CLOSED ERRATA QA Contact: Jan Blazek <jblazek>
Severity: medium Docs Contact:
Priority: low    
Version: 8.6CC: amatej, amepatil, byodlows, james.antill, jkolarik, mbanas, rmetrich, thomas
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: dnf-4.7.0-13.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 2125167 (view as bug list) Environment:
Last Closed: 2023-05-16 09:06:59 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:
Bug Depends On:    
Bug Blocks: 2125167    

Description adrian 2022-06-24 10:52:04 UTC
Description of problem:
If I run a yum install command, it will delete the contents of the directory I had previously downloaded rpms into using the downloadonly and destdir commands. I don't think yum should even remember the destdir as this could be used by completely separate processes and having the files deleted from there is unexpected behaviour in my opinion.

Version-Release number of selected component (if applicable):
All versions of RHEL8 tested had the issue including 8.3 and 8.6

How reproducible:
Every time

Steps to Reproduce:
1. Download wget into /tmp/adrian/ using yum --downloadonly --destdir=/tmp/adrian/ reinstall wget -y
2. Confirm /tmp/adrian/wget*.rpm is present
3. Install another package: yum reinstall vim -y
4. Confirm that /tmp/adrian/wget*.rpm is now removed

Actual results:
The wget rpm has been removed

Expected results:
Yum should not touch my destdir folder at all

Additional info:

Comment 1 amatej 2022-06-27 14:02:36 UTC
We have already discussed this a few times and most likely the best behavior would be indeed not to touch users destdir but still clean up the default cache.
There also is at least one fedora bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=2080334 - it mentions a workaround - using the dnf download plugin.

It is unlikely that we will change this for rhel-8/rhel-9 though, possibly in dnf5.

Comment 2 Jaroslav Mracek 2022-07-13 06:39:50 UTC
The problem is that `--destdir` option is used with `--downloadonly`` option for command that creates a transaction but also for commands `download`, `system-upgrade`, `reposync`, `modulesync`. Specially I do worry about `system-upgrade` where the option is used to redirect required downloads to a different volume because limited space. Then it is expected to delete such packages after successful transaction. I also believe that the user case with system-upgrade is also valid with other command. The problem is that DNF does not know the intention of the user. It sees only commands, options and arguments. What about to create a new option or use configuration option keepcache (https://dnf.readthedocs.io/en/latest/conf_ref.html) and extend the functionality. What do you think?

Comment 3 adrian 2022-07-15 10:30:47 UTC
(In reply to Jaroslav Mracek from comment #2)
> The problem is that `--destdir` option is used with `--downloadonly`` option
> for command that creates a transaction but also for commands `download`,
> `system-upgrade`, `reposync`, `modulesync`. Specially I do worry about
> `system-upgrade` where the option is used to redirect required downloads to
> a different volume because limited space. Then it is expected to delete such
> packages after successful transaction. I also believe that the user case
> with system-upgrade is also valid with other command. The problem is that
> DNF does not know the intention of the user. It sees only commands, options
> and arguments. What about to create a new option or use configuration option
> keepcache (https://dnf.readthedocs.io/en/latest/conf_ref.html) and extend
> the functionality. What do you think?

The 'man yum' help says 'downloadonly is for downloading package without performing any yum transaction' and the 'destdir' flag help doesn't mention that is it changing the yum cache location.

I did not know about the dnf config value keepcache - that does seem to help with this issue - thanks for letting me know. Although for regular yum use I probably don't want that enabled. Maybe I can pass in a --setopt value for keepcache to my yum command?

It feels like yum should not treat the destdir as a cache location by default - it should forget it as soon as the command is finished, or at least have a flag to let the user choose to use a custom cache location e.g. --cache_folder= instead of --destdir=, because then it is clear to the user that caching properties will come into play

Or at least change the 'yum help/man yum' output to make it clear that the destdir folder is effectively a temporary cache location - that is probably lowest effort change if needed.

Comment 5 Jaroslav Mracek 2022-08-31 14:04:43 UTC
Because there is a workaround and we cannot change easily the default behavior we can only update the documentation including the workaround.

AC: Improve documentation related to use --downloadonly option and to --destdir where after successful transaction DNF will remove such a packages because they are considered as a part of dnf cache.

Comment 6 Jan Kolarik 2022-09-07 11:13:47 UTC
I've added a note to documentation about the current behavior. I will think about possible changes of this behavior related to DNF5.

Following PR was queued to fix this:

https://github.com/rpm-software-management/dnf/pull/1850

Comment 7 Jan Kolarik 2022-09-08 08:13:28 UTC
Cloned into RHEL 9 ticket https://bugzilla.redhat.com/show_bug.cgi?id=2125167.

Comment 13 Jan Kolarik 2022-11-16 07:17:59 UTC
*** Bug 2142934 has been marked as a duplicate of this bug. ***

Comment 14 Eva Mrakova 2022-12-19 12:22:34 UTC
*** Bug 2153042 has been marked as a duplicate of this bug. ***

Comment 17 errata-xmlrpc 2023-05-16 09:06:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dnf bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2980