Investigate the principle how libeconf works

[j-mracek]

Project https://github.com/openSUSE/libeconf provides a possibility of managing of configuration and repository file. To enable the support of the same mechanism and compatibility with Suse distributions we need to know in details

• how the mechanism works
• the location of an alternative paths where configuration will be stored
• whether libeconf supports configuration option priority (Required for a proper handling of installroot and related paths)

Without an active support from community it will be difficult to implement it.

[Conan-Kudo]

I think @schubi2, @dmach, and @sysrich can probably help here, maybe?

[michel-slm]

This will be nice to have. The use case I have in mind is being able to override DNF repo configs, the way systemd service definitions can be overridden by dropping additional config files.

e.g. for CentOS Stream, epel-release will be able to drop an additional config to enable CRB repo if centos-release is present

[j-mracek]

Anyone know the state of implementation of the feature in Suse distributions? If the feature is not alive please let us know.

[sysrich]

It’s alive, and used in various places across the distribution. Tumbleweed has successfully moved all its binaries to /usr and libeconf is part of the glue that made that possible.

On Thu 17. Feb 2022 at 07:40, Jaroslav Mracek @.***> wrote:

Anyone know the state of implementation of the feature in Suse distributions? If the feature is not alive please let us know.

— Reply to this email directly, view it on GitHub https://github.com/rpm-software-management/libdnf/issues/1387#issuecomment-1042656784, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJENIFZVRVP7B6G3ZHGUWDU3SQ5NANCNFSM5JBWP5KA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[Conan-Kudo]

So what I'm planning to go with is the following:

• /usr/share/rpm.repos.d (or /usr/share/yum.repos.d) for the vendor/package provided repo files
• /usr/share/rpm.repo.vars.d (or /usr/share/yum.repo.vars.d) for vendor/package provided var files
• /etc/rpm.repos.d (or /etc/yum.repos.d) for admin provided repo files or overrides for vendor/package provided repo files
• /etc/rpm.vars.d (or /etc/yum.vars.d) for admin provided vars that fully override vendor/package provided vars

My preference is for the former path, but if you want to use the alternative one in parenthesis for backwards compatibility, I'm fine with that. Files in /etc can be either full repository definitions (and thus completely overriding the content in /usr) or files that just contain the repo ID and select values to override (e.g. CRB disabled by default by CentOS Stream, EPEL overriding that to turn it back on).

Does this make sense for you all to implement for DNF 5?

[lukash]

• /usr/share/rpm.repo.vars.d (or /usr/share/yum.repo.vars.d) for vendor/package provided var files

Why not /usr/share/rpm.vars.d (keep the name the same for both /etc/ and /usr/share/).

Otherwise LGTM and I think we'll need to keep the yum.* variants as compatibility fallbacks for those dirs that are in use now? For those that aren't, I wouldn't introduce them.

[j-mracek]

lets discuss details: /usr/share/rpm.repos.d - It is expected that it contains full and functional description of repository /etc/rpm.repos.d Is it expected that it contains only overrides for repository defined in /usr/share/rpm.repos.d. When repository in /usr/share/rpm.repos.d will be not present then data in can be ignore it or the repository will be created and if it contains a minimum, it can be used. Personally I would prefer to use /etc/rpm.repos.d only for overrides of /usr/share/rpm.repos.d`and not for creation of a new repository because we do not know what was with data intended. Why it is important: To prevent errors and unnecessary requirements of user interaction when set of repositories is changed.

[dmach]

If /etc/rpm.repos.d should contain only overrides, they you're breaking some assumptions and compatibility with the existing behavior. For an inspiration, I found a relatively short article about how systemd does it: https://www.kaffeinlabs.com/posts/19-systemd-unit-overrides/. You can try the following command yourself: systemctl edit dnf-makecache.timer [--full] Please beware that with --full it creates /etc/systemd/system/dnf-makecache.timer you need to remove afterwards.

Also please note that rpm.repos.d may not be ideal directory name in case dnf goes beyond rpm in the future. On the other hand, the only currently supported repo type is rpm-md (with aliases: rpm, repomd, rpmmd, yum, YUM) and nothing more. How about to remove rpm/yum/dnf from the name completely and use repos.d and repo-vars.d?

Maybe we should define a common denominator among rpm-based package managers. I think it should be:

• repos
• repo vars
• list of protected packages (that must not be removed from the system)
• list of installonly (multiversion) packages
• reasons: userinstalled / dependency
• not sure about locks/versionlocks

With this information shared among the package managers, they should behave relatively reasonably even if someone decides to use them in parallel.

How about the following?

# data from packages:
/usr/share/pkg/repos.d
/usr/share/pkg/repo-vars.d
/usr/share/pkg/lock.d (== dnf's versionlock, zypper's lock (they work differently, can they be unified at all?))
/usr/share/pkg/multiversion.d (== installonly)
/usr/share/pkg/protected.d

# compat layer (symlinks, but could work as standalone dirs too)
# files from this layer completely replace files from `/usr/share`
/etc/pkg/repos.d -> /etc/yum.repos.d
/etc/pkg/repo-vars.d -> /etc/dnf/vars

# overrides, applied only if the corresponding configuration file exists
/etc/pkg/overrides/repos.d
/etc/pkg/overrides/repo-vars.d
/etc/pkg/overrides/lock.d 
/etc/pkg/overrides/multiversion.d
/etc/pkg/overrides/protected.d

# system state
/usr/lib/sysimage/pkg/userinstalled
/usr/lib/sysimage/pkg/autoinstalled (== deps)
^^^ it's quite important to store both in order we can easily identify packages installed/removed by calling `rpm` directly.

[Conan-Kudo]

I'm fine with that, keep in mind that these directories will be owned by rpm-repos-openSUSE and dnf-data in openSUSE. For RH/Fedora, that ownership will be split between fedora-repos and dnf-data.

[Conan-Kudo]

Also please note that rpm.repos.d may not be ideal directory name in case dnf goes beyond rpm in the future. On the other hand, the only currently supported repo type is rpm-md (with aliases: rpm, repomd, rpmmd, yum, YUM) and nothing more. How about to remove rpm/yum/dnf from the name completely and use repos.d and repo-vars.d?

The naming is deliberately so it can be used by multiple package managers, and for different package types, I'd rather have DNF read different directories, like how SmartPM did.