According to the dnf documentation it should be possible to control this by setting the system_state_dir option in the [main] section of /etc/dnf/dnf5.conf (or /etc/dnf/dnf.conf, depending on where in the documentation one reads). I tried putting the following in both /etc/dnf/dnf5.conf and /etc/dnf/dnf.conf:
[main]
system_state_dir=/var/lib/sysimage/libdnf5
But after setting system_state_dir, dnf system-upgrade still downloads to /usr rather than /var. Any idea why this configuration option isn’t having the intended effect?
However, according to the docs, the directory specified as the system_state_dir is used to:
Store the reasons why each installed package was added to the system. The reasons can be “user” for packages that the user explicitly asked DNF5 to install, “dependency” and “weak dependency” for packages pulled in as dependencies of another package, “group” for packages installed by a group, or “external” for packages installed by another tool (e.g. rpm).
Track installed groups and packages installed by these groups.
Track installed environmental groups.
It doesn’t sound like it’s the directory that packages are actually downloaded into.
By default, the packages are downloaded to /usr/lib/sysimage/libdnf5/offline, but I would think it would make more sense to download the packages to a cache directory
Following the trail from that, it looks like this change will download packages into persistdir (which by default is /var/lib/dnf) instead of somewhere under /usr.
I’m confused by the discussion in dnf system-upgrade downloads several gigabytes to /usr/lib (#2398). The phrase “hard coded” is used at least twice, but in one of those places it says the path is “currently hard-coded to the system state dir.” This would seem to contradict the documentation saying system_state_dir can be overridden with a config file might be incorrect. Can anyone confirm whether system_state_dir can in fact be overridden?
Thanks, I did just that and it worked. Had previously hesitated to do that based on the discussion in Dnf system-upgrade, package location in which it was suggested that the symlink approach might require some “bravery” but I encountered no problems.