On Thu, Mar 2, 2017 at 10:51 AM, Mike McLean mikem@redhat.com wrote:

On 03/02/2017 03:51 AM, Miroslav Suchý wrote:

...

Dne 1.3.2017 v 21:04 Dennis Gregorovic napsal(a):

...

https://github.com/rpm-software-management/mock/pull/51

This is something that could impact koji if there is a need to support this feature. It's worth checking out.

Definitely worth checking as it is big change.

Can you elaborate how it can affect Koji? Yes, koji builders' does not use networking, but AFAIK only in chroot and it is set by config['use_host_resolv'] = False Which we explicitly set to true for the bootstrap chroot. And BTW it does not mean that there is no network, just no resolvers so only access using DNS does not work.

We don't know that it will, but any big change in mock might. We might for example need to adjust the mock configs we generate.

I think it'd make sense to have the double-chroot mode enabled in most (if not all) reasonable cases of Koji being used. In Mageia, we do this with iurt and YOURI so that we can leverage improvements without having to completely rebuild the buildsystem for each release (Factoid: up until last year, the build system was running on Mageia 1, but we could build and ship packages that used features in newer versions of RPM because of this).

A simple example: with mock as it is now, it's impossible to use COPR to build packages targeting Mageia using all the official macros provided in rpm-mageia-setup (our equivalent of redhat-rpm-config) if the host system is CentOS or Fedora from something like dist-svn or dist-git. The reason is that our rpm is different, and there are special base macros that simply don't exist on CentOS/Fedora. By doing double-chroot, it means that the SRPM generation step now doesn't occur using the host configuration, and always occurs on the target.

Koji doesn't *quite* suffer from this problem, but it suffers from another: chroots depend on the system rpm and dnf for processing dependencies of spec/srpm. This is especially a problem if there's a feature in newer RPM/DNF that system RPM/DNF/Yum doesn't understand. If it's always double-chroot, we can avoid that entirely. This is also a problem in COPR, too, which led to us in Rust SIG being completely unable to use the system.

In fact, the feature was developed specifically because of us needing to use more advanced rich dependency features, and the host being stuck and unable to support it.