include releasever and arch in cachedirs about libdnf HOT 5 OPEN

There is one concern during rebase if we were to add releasever/ basearch suffix to the cache directory. Currently, we are still fetching os-release information from etc/os-release. However, during rebase, the os-release file will not get modified until a reboot happens. The cached information will therefore still not get updated during a rebease.( What will be a reasonable solution to this?).

If you look at https://github.com/projectatomic/rpm-ostree/blob/0ff4403253b8fd6af8a4d468aaff7ad11f300f23/src/daemon/rpmostree-sysroot-upgrader.c#L800, we tell libdnf to use the tmpdir where we checked out the new commit to find the releasever information. In #215, libdnf learned to look in usr/etc/os-release. Though that's not used now in the rpm-ostree path since #278, which makes libdnf actually look in the rpmdb of the new commit as well. If you don't see the releasever from the new commit being used, then I suspect something in that flow is failing.

from libdnf.

So dnf does this: https://github.com/rpm-software-management/dnf/blob/00c8fe31cf82c393f8d903c3a191ac399a8b6c19/dnf/repo.py#L405

Using a short hash seems a bit weird; do we ever expect any substitutions beyond basearch and releasever?

from libdnf.

Also, maybe we should have clean operations here; specifically for rebases, if we do separate by releasever/basearch, we want to clean up the old repo.

from libdnf.

There is one concern during rebase if we were to add releasever/ basearch suffix to the cache directory. Currently, we are still fetching os-release information from etc/os-release. However, during rebase, the os-release file will not get modified until a reboot happens. The cached information will therefore still not get updated during a rebease.( What will be a reasonable solution to this?). But I am thinking may be it is a wanted behavior, because the system is still in the old version when no reboot happens, and it makes sense that before system version change, the cache should remain same?

However, there is another interesting pattern that I noticed. It seems like the cache directory still remains after a rebase(after reboot) occurs, and whenever a user tries to install a package, the operations will fail due to the presence of the old cache. This problem, however, can be solved by checking the releasever because the suffix of the cache directories will be different.(as os-release gets changed)

In that case , would it be better if we just expires the metadata during a rebase, and we do a similar step again when a roll back takes place?

from libdnf.

ah, I thought it wrong in the first place,... now things start to make sense :p, will look further into the issue after this. thanks @jlebon! :D

from libdnf.