RFC host configs

[xsuchy]

trafficstars

Today mock parse:

1. site-defaults.cfg
2. chroot config (e.g. fedora-28-x86_64.cfg)
3. user configs

I want to add a new set of configs. E.g. host-fedora-28.cfg, host-rhel-7.cfg, etc. When mock will be run on RHEL7 then it will read host-rhel-7.cfg. When mock will be run on Fedora 28 then it will read host-fedora-28.cfg (if it exists).

This should solve some issue when some platform needs some different defaults.

I just wonder which order is better?:

1. first read chroot config and then host-* config or
2. first read host-* config and then read chroot config

Option 1 will allow me to override package manager for fedora chroots on RHEL7. Option 2 .... are there some benefits?

Comments?

[Conan-Kudo]

Host configs are not going to be useful except for exactly one case: bootstrap chroot. And potentially, not even then.

The assumption here is that the host configuration files will help with making package builds of newer Fedora releases on RHEL 7 work. But the answer to that is probably that it won't work even then. This is largely due to our usage of rich dependencies in the system. And this is not just in the Requires tag, but also in weak tags like Recommends and Suggests.

The thing is, RHEL 7's RPM and YUM is partially capable of processing weak dependencies, too, so that means that once it hits a weak tag that has a rich dep description, bad things are probably going to happen. This can definitely happen even in the bootstrap phase.

We get into ugly territory here, because RHEL 7 is too long in the tooth, and yet has been somewhat enhanced over the years to try to keep up a little bit with Fedora.

If you treat the package manager selection as an override, wouldn't that also mean that the wrong package manager would be used for selecting dependencies across the board, too? And with regular mode (no bootstrap), this would be much worse...

[praiskup]

This should solve some issue when some platform needs some different defaults.

This looks like the host-*.cfg is to some extent alternative to site-defaults, and thus it looks like it should be parsed right after site-defaults.

[jcpunk]

Would you be fetching the host type from /etc/os-release or some other detection?

[xsuchy]

Would you be fetching the host type from /etc/os-release or some other detection?

I would like to rely on python-distro detection.

[voxik]

I am looking for something more generic, like configurations for nested roots.

E.g. my host is Fedora Rawhide and I want to build EPEL6 packages. That means I'd like to be able to specify that the outer (bootstrap, but this is very limiting term) root will be using DNF from my host system and the bootstrap will have installed YUM from some repository (I will decide myself if the YUM should come from RHEL or Fedora or a different source). The inner root should be using "EPEL6" config, as if I was building EPEL6 packages on EPEL6.

This should also allow going even deeper, like installing YUM from Fedora by host DNF, in the second layer installing RHEL YUM using Fedora YUM and then finally using the 3rd layer root to build packages.

Also, this would make mock more generic tool, possibly allowing other RPM package managers, not just YUM or DNF. This would allow dropping --dnf and --yum options, which are honestly not very conceptual.

BTW wherever I am referring to YUM/DNF, I should refer to RPM as well, the old version of RPM on RHELs is probably the reason behind this RFC.