[Gluster-devel] Removing glupy from release 5.7

Michael Scherer mscherer at redhat.com
Thu Jun 20 13:05:56 UTC 2019

Le jeudi 20 juin 2019 à 08:38 -0400, Kaleb Keithley a écrit :
> On Thu, Jun 20, 2019 at 7:39 AM Michael Scherer <mscherer at redhat.com>
> wrote:
> > Le jeudi 20 juin 2019 à 06:57 -0400, Kaleb Keithley a écrit :
> > > AFAICT, working fine right up to when EPEL and python3 were
> > > installed
> > > on
> > > the centos builders.  If it was my decision, I'd undo that
> > > change.
> > 
> > The biggest problem is that mock do pull python3.
> > 
> > 
> That's mock on Fedora — to run a build in a centos-i386 chroot.
> Fedora
> already has python3. I don't see how that can affect what's running
> in the
> mock chroot.

I am not sure we are talking about the same thing, but mock, the rpm
package from EPEL 7, do pull python 3:

$ cat /etc/redhat-release;   rpm -q --requires mock |grep 'python(abi'
Red Hat Enterprise Linux Server release 7.6 (Maipo)
python(abi) = 3.6

So we do have python3 installed on the Centos 7 builders (and was after
a upgrade), and we are not going to remove it, because we use mock for
a lot of stuff.

And again, if the configure script is detecting the wrong version of
python, the fix is not to remove the version of python for the
builders, the fix is to detect the right version of python, or at
least, permit to people to bypass the detection.

> Is the build inside mock also installing EPEL and python3 somehow?
> Now? If so, why?

No, I doubt but then, if we are using a chroot, the package installed
on the builders shouldn't matter, since that's a chroot.

So I am kinda being lost.

> And maybe the solution for centos regressions is to run those in
> mock, with a centos-x86_64 chroot. Without EPEL or python3.

That would likely requires a big refactor of the setup, since we have
to get the data out of specific place, etc. We would also need to
reinstall the builders to set partitions in a different way, with a
bigger / and/or give more space for /var/lib/mock. 

I do not see that happening fast, and if my hypothesis of a issue in
configure is right, then fixing seems the faster way to avoid the
Michael Scherer
Sysadmin, Community Infrastructure

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190620/ad358fe7/attachment-0001.sig>

More information about the Gluster-devel mailing list