-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
context: vars dirs prefixing is problematic #1503
Comments
While looking into the rpm-ostree issue, we found out that PackageKit also carries some vars_dir logic which does not expect libdnf to internally do any prefixing:
There is an ongoing thread about this at https://github.com/PackageKit/PackageKit/pull/369/files#r863937752. |
This drops the internal prefixing logic for vars directories, thus avoiding the prepended `install_root` path prefix on all entries. It also results in aligning the behaviors of `dnf_context_set_vars_dir()` and `dnf_context_set_repos_dir()`. Existing consumers in the wild are not really expecting this kind of prefixing to happen internally. Additionally, developers seem to naturally assume that the lookalike APIs for repos-dir and vars-dir behave in the same way. Ref: coreos/rpm-ostree#3241 Ref: https://github.com/PackageKit/PackageKit/pull/369/files#r863937752 Closes: rpm-software-management#1503
Looking at the two cases above from distinct projects/developers, they seem to share some common expectations:
Based on the those observations, I've submitted a patch at #1506 which covers all of the above by removing the internal prefixing step. |
I think I found one more case in
and then the CI exercises it with explicit prefixing:
|
Additionally, @jrohel noted in PackageKit/PackageKit#369 (comment):
Which I read as an hint that this libdnf behavior was maybe not really expected/designed as currently implemented. |
(This issue originated at coreos/rpm-ostree#3241, which contains more details about the context)
rpm-ostree
internally useslibdnf
for handling packages and repositories details. This includes sourcing repositories and variables content from the filesystem (e.g. runtime config such as/etc/yum.repos.d
and/etc/dnf/vars
).As library consumers, we are currently having some troubles because all the vars directories are internally prefixed with
install_root
:libdnf/libdnf/dnf-context.cpp
Lines 3782 to 3791 in 0ee4144
Thus all the vars lookups are happening at
<install_root>/etc/dnf/vars
instead of/etc/dnf/vars
.I'm not sure if this behavior was intended, but the hardcoded prefix makes it harder to do out-of-band installs.
This behavior is also puzzling because repos lookups do not go through the same
install_root
prefixing, even though the external API for the two entities is basically the same:libdnf/libdnf/dnf-context.cpp
Lines 1177 to 1187 in 0ee4144
libdnf/libdnf/dnf-context.cpp
Lines 1227 to 1237 in 0ee4144
For our specific usecase we would be happier without the internal prefixing, so that
vars_dir
behaves the same way as the existingrepo_dirs
logic.If you believe that
libdnf
should instead keep doing its own internal prefixing, we'd need some kind of API to set the prefix back to/
separately frominstall_root
(which in our case is already set to a different path).The text was updated successfully, but these errors were encountered: