On Thu, Mar 2, 2017 at 10:51 AM, Mike McLean <mikem(a)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.
--
真実はいつも一つ!/ Always, there's only one truth!