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.

[nkadel]

that would need a major release number update. Any chance of publishing that with semantic versioning? 3.0.0, and even linking it to the mock-core-conigs?

I'm not enamored of the "stateless Linux" movement, nor am I enamored of the "let's put 3 more places to layer configs". Adding additional layers seems unnecessary and to me, at least, unwelcome. If they really need to live in /usr/share/, of which I'm not personally convinced..... yeah, it's going to break a lot of tools, and needs a branch or clone in which the changes can be tested long before distribution to Fedora and EPEL. Any chance of calling it "mock3" the way python 3.x was published as python3 ?

[Conan-Kudo]

that would need a major release number update. Any chance of publishing that with semantic versioning? 3.0.0, and even linking it to the mock-core-conigs?

Did you read my comment? I just said it's coming with Mock 3.0. When the Mock branches are split, mock-core-configs splits along with it, so yes, they'll be necessarily tied to Mock versions anyway.

I'm not enamored of the "stateless Linux" movement, nor am I enamored of the "let's put 3 more places to layer configs". Adding additional layers seems unnecessary and to me, at least, unwelcome. If they really need to live in /usr/share/, of which I'm not personally convinced..... yeah, it's going to break a lot of tools, and needs a branch or clone in which the changes can be tested long before distribution to Fedora and EPEL. Any chance of calling it "mock3" the way python 3.x was published as python3 ?

No. This is not an interface breakage with the interfaces we promise. We only promise the mock CLI, and that behavior is remaining the same.

[nkadel]

I read the note. I'm suggesting "mock-3.0.0" rather than "mock-3.0", to provide semantic versioning compatible with most other Linux packages. That might have helped with mock-2.16 and mock-core-configs-36.4 published in tandem with it. It could leave mock and mock-core-configs to use matching releases, and small changes that only noticeably affect one of them could only update the third number in semantic versioning. The disparate numbering between mock, and mock-core-configs, with both of them in the same git repo remains confusing.

I don't want to hold up anything with that sort of suggestion.

[praiskup]

Ad versioning, we'll most likely go with mock-3.tar.gz, then mock-3.1.tar.gz, then mock-3.2.tar.gz, etc. There's no plan to change the versioning of mock-core-configs at this moment.

[nkadel]

Looking back at this: "not mounting /etc" does not seem like a useful design goal. I'm aware that Leonard Pottering and the "stateless Linux" projects have been trying to eliminate /etc/ published config files, but it's not going away. And my point that this will break config files is not that it will have new locations, but that it will move aside the files from the old locations where various config tools currently know to tune them in place, or reference them with an "include" statement, rather than publish entirely new files. I use this technique myself for doing builds with a local copy of mock and with modularity enabled for python38 on RHEL 8, or adding local dnf repos.

[Conan-Kudo]

Perhaps as a way to move things forward, would moving the configs to /usr/share and add stubs in /etc work to get the ball rolling? If so, I can prepare a pull request to do this.

[sincerelysaucy]

I think the idea that "nothing should read config files from /etc/" is an unwelcome, unnecessary, and pretentious change in more than 30 years of UNIX default practice. It's likely to introduce undesirable and unwelcome changes between systems running mock-2.x and mock-3.x. I suggest that time spent trying to retrofit the change to "/usr/share/" for compatibility with ansible, puppet, chef, and local config settings like I personally use for doing Samba, OpenSSH, git, and ansible debugging is time better spent elsewhere.

That said, if this is thought to be really worth the hassle, I'm willing to test it specifically for mock and mock-core-configs on the base OS's I have access to, which are primarily RHEL based.

[nkadel]

Sorry for confusion, I'm setting up a separate account for distinct projects. That was me as "sincerelysaucy".

[Conan-Kudo]

The goal isn't to get rid of /etc for configs, it's to make it so only admin-controlled configs are there. Packaged stuff should not be there if at all possible.

[praiskup]

I think that we should have some documentation on how to package these "systemd-like" configuration files in general. Perhaps admitting that this is known to break FHS, or that we are in "gray zone" at least.

I don't see a practical benefit to this change that would outweigh the breaking change effects. Mock users shouldn't modify /etc files nowadays ideally (but files in $HOME). If we want to comply with some initiative (e.g. "evacuate /etc" like here), I'm for the standardization - but isn't the initiative worth documenting first?

[nkadel]

What would this take to do?

• /etc/mock/site-defaults.cfg stays where it is?
• A suite of .cfg files with Yet Another Naming Scheme are left in /etc/mock/ and /usr/share/mock/
• The search order for the "mock -r configname" command is revised to look for files with or without the .cfg suffix in $PWD, /etc/mock/ and /usr/share/mock/ ? In that order?

$HOME is not where you want to tweak things for mock if you want other developers to get your tweaks. This particularly applies to settings like the URLs for RHEL in AWS and Azure hosts, where the default RHEL images use internal RHEL mirrors which mock doesn't know about by default.