Most Mock configs are static and should be in /usr/share rather than /etc

[Conan-Kudo]

Short description of the problem

A lot of people erroneously believe that most of the Mock build environment configs are intended to be user-edited configuration files. Aside from default.cfg (which is its own pain...), this is actually not true. We should consider moving all the static configuration out of /etc/mock and into /usr/share/mock instead so that this is accurately represented.

[praiskup]

This would make only sense if /etc/mock was also provided, and users were able to override the defaults from /usr/share/mock. Otherwise, it was intentional to claim those are configs.

[Conan-Kudo]

Yes, I think so. We should have both and allow overrides in /etc/mock.

[praiskup]

Currently, most users don't know thoug that ~/.config/mock is the place where users can install the overrides, so touching this (when it works just fine) doesn't make much sense to me.

[xsuchy]

Well, you can edit the configs. And manage them using e.g., rpmconf.

[praiskup]

To continue on my idea, why I think it doesn'ŧ make much sense ... The problem is that mock isn't a typical multi-user tool. If you grant someone the mock system group - you give him everything. So mock typically isn't a tool for multi-user boxes. Therefore I think that ~/.config/mock enough for the single-user scenarios.

[Conan-Kudo]

Sure, but that tool isn't used by default and hardly anyone knows about it. And we're generally trying in Fedora to reduce the stuff that is package manager controlled in /etc so that the system is more robust and eventually tolerate stuff like trivial factory reset by wiping /etc.

[praiskup]

The benefit would be that we can run mock without /etc mounted ... which brings a little to zero benefit to me. Otherwise, living with /etc (untouched) + ~/.config/mock should be enough.

[Conan-Kudo]

It makes it easier for Mock to work and update properly on transactional-update (openSUSE MicroOS) and rpm-ostree based systems (Fedora Silverblue/Kinoite/CoreOS) if we make this change, too.

[xsuchy]

I am +1 to move it. And continue to talk how to do that. But please postpone it to 3.x version. I.e. when we put 2.x version to maintenance mode and separate bug-fix branch. I would like to do that after we resolve the epel-8 config thing.

[Conan-Kudo]

I'm fine with moving it in Mock 3.0.

[praiskup]

Shouldn't we use "/usr/lib" instead of "/usr/share"?

[praiskup]

There's one inconsistency we should accept here:

If we move all the default configuration to /usr/share or /usr/lib (the directory needs to be picked here first, before #817 is merged), we'll have to treat site-defaults.cfg and chroot configs differently. Namely:

• anything in %config %immutable_confdir/site-defaults.cfg will be complemented by the %ghost/%config(noreplace) site-defaults.cfg
• and chroot %config will be replaced by the "%ghost" /etc/mock/ config

[Conan-Kudo]

Shouldn't we use "/usr/lib" instead of "/usr/share"?

The config files themselves are architecture independent and are identical across architectures, so /usr/share is much more appropriate.

[praiskup]

Any documentation we should follow on this problem?

[Conan-Kudo]

Mainly FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

[praiskup]

I think we agreed to not exactly "comply" with FHS (if there's documentation how configuration files should be maintained, not data).

[Conan-Kudo]

Well, if we move to an override mechanism, then these files are static. And even today, most people treat them as static.

Ideally, we'd use /usr/etc, but I think RPM-OSTree blocks us from using that.

[praiskup]

Yes, I was about to ask about that ... why are they blocking us?

[Conan-Kudo]

Yes, I was about to ask about that ... why are they blocking us?

I believe RPM-OSTree reserves /usr/etc for its config staging redirection stuff, but @cgwalters would know more there.

[cgwalters]

Ah...it's more that you get /usr/etc for free on ostree based systems to reflect the defaults of /etc. But applications in general shouldn't load files from there.

It's better to use /usr/share or /usr/lib; or even better use a shared library which implements "systemd style" config management.

[praiskup]

Shared lib sounds like overkill in this case. And ad the /usr/share and /usr/lib, I'm sure we should first make sure that this topic is generally documented somewhere (at least in Fedora guidelines).

[xsuchy]

I'm sure we should first make sure that this topic is generally documented somewhere (at least in Fedora guidelines).

@cgwalters would you be willing to drive this through FPC? Or, ehm, to FHS directly?

[Conan-Kudo]

Why would this require FPC or FHS?

[praiskup]

This should be documented somewhere, at least on the Fedora level. It is better than arguing personal opinions about what is better. FTR, I agree with @Conan-Kudo that /usr/share sounds better, even though these are data files. But contrary to our opinion, this goes against the usual practice:

$ rpm -q -a -c | grep /usr/share/ | wc -l
4
$ rpm -q -a -c | grep /usr/lib/ | wc -l
21

And similar data on all the systems I had a quick chance to try (I haven'ŧ tried to install everything). Before we do this change (which is a low priority one anyway), we should have an authoritative link to docs.

But I really don'ŧ think we should attempt FHS at this point in time :-) it is long shot.

[nkadel]

The "/usr/lib/" query left out "/usr/lib64" . The /usr/lib config files are, frankly, mostly "/usr/lib/jvm/", and Java is frankly, its own special playpen.

[praiskup]

Not just Java, and /usr/lib was being used probably because those config files are arch-agnostic. @nkadel, would you mind helping us to standardize this?

[nkadel]

Standardize /usr/lib/jvm/ ? Not touching that with a 10-foot pole.

Migrating /etc/mock/ to /usr/share/mock/ ? Hmm. It seems straightforward at first glance, but at second glance it seems very likely to break configuration management tools for our build environments. tools like chef, ansible, puppet, and l even ahndwritten configuration scripts. It will even break my Makefiles for RPM building suites for backporting samba, ansible, mock and awscli to older operating systems. While it may be an FSH violation, I'm very hesitant indeed to alter these in a non-backwards-compatible way.

Is any thing really needed other than a more explicit README.md associated with the packages ?

[Conan-Kudo]

@nkadel /etc/mock wouldn't go away. Indeed, if you wanted to install config files there, it should work fine. What I want is all the packaged configs to /usr/share/mock. This actually would make things easier for config management to apply overrides while making it easy to "reset" back to the factory provided ones.

[nkadel]

Moving things and expecting the configuration tool author and users to keep up is likely to break other people's software. The return on the investment of a new layout with bits in /etc/mock/ and bits in /usr/share/mock/ seems unwise and unwelome to me as a configuration manager. I build mock .cfg files for local configurations using /etc/mock/epel-7-x86_64.cfg and the like as references, What would you put un /usr/share/mock/ ? The template files?

[Conan-Kudo]

Moving things and expecting the configuration tool author and users to keep up is likely to break other people's software. The return on the investment of a new layout with bits in /etc/mock/ and bits in /usr/share/mock/ seems unwise and unwelome to me as a configuration manager.

It's why we're doing it for Mock 3.0. It's a major change and it makes sense to do it when we gut all the hacks we have for older host platforms too.

Like it or not, this is a trend across all software in Linux distributions. Configuration in SUSE distributions are moving to a scheme where shipped/vendor/packaged configs are in /usr/etc, /usr/share, or /usr/lib (in order of preference) so that stateless Linux bring-up becomes possible and that it becomes easier to implement things like factory reset or Linux platforms that resist hysteresis. RH/Fedora is moving in a similar direction, we just don't get to use /usr/etc because RPM-OSTree reserves it.

I build mock .cfg files for local configurations using /etc/mock/epel-7-x86_64.cfg and the like as references, What would you put un /usr/share/mock/ ? The template files?

All of the files we ship in mock-core-configs except default.cfg would move. The templates, the top-level configs, etc. would move. All that would be left in /etc/mock would the files that you add/modify/override. For example, if you wanted to have your own rhel-9-x86_64 config pointing to a local content mirror, you'd drop it in /etc/mock, which would shadow the one we provide in /usr/share. This enables you to do even more interesting things, like leverage RHEL content without all the downsides of subscription-manager.

You could even do interesting things like including the vendor provided configs and layering your own changes. For example, you might have your own common modules that you'd want to make available, and you can write configs that import and shadow the originals and extend them as you need.