Re: Propose requiring Python 3.4 or later for building glibc.

[Carlos O'Donell <carlos at redhat dot com>]

On 10/22/18 10:15 AM, Helmut Grohne wrote:
> On Mon, Oct 22, 2018 at 11:51:25AM +0200, Aurelien Jarno wrote:
>> On 2018-10-19 09:47, Carlos O'Donell wrote:
>>> This proposal is to being circulated to all the distribution
>>> maintainers to gain their acceptance surrounding the use of
>>> python 3.4 or greater for building glibc.
>>>
>>> There has been concern expressed that requiring python 3.4
>>> or greater for the bootstrap process will add an additional
>>> tool the the bootstrap, and specifically a tool that may not
>>> be available on older distributions.
>>>
>>> Python is already mostly available for distributions because
>>> of the integration into key OS components. Python can be 
>>> built on older distributions, and on older distributions you
>>> already have to build a lot of things to compile glibc (like
>>> a newer gcc, and binutils).
>>>
>>> The question today is:
>>>
>>> * Is it OK to require python 3.4 or later to build glibc?
>>
>> [...]
>>
>>> Aurelian,
>>>
>>> Any input from Debian?
>>
>> From the Debian side, the version 3.4 is not an issue at all. The
>> default Python 3 version in unstable (which is relevant for future
>> versions of glibc) is already 3.6.
>>
>> We also need to consider the process of bootstrapping Debian. In that
>> case I believe it should also be fine as Python 3 from the host system
>> can be used. I have added Helmut Grohne in Cc: who is much more aware
>> of the bootstrapping process than me, and can confirm or infirm that.
> 
> I fear we need more precision here. There are multiple ways to bootstrap
> Debian. There is "cross bootstrap" for jumping from one Debian
> architecture to another, which is what I work on. As long as glibc only
> needs to run the build architecture Python, I see no problems here. 

OK, good.

> I assume that you are not trying to integrate with the host architecture
> Python as that would pose interesting problems. Given that Debian's
> cross bootstraps are version locked, I don't see problems with requiring
> recent versions either. In contrast, I'd love to be able to use Python 3
> in Debian's glibc packaging. Also note that Debian's linux packaging
> already requires Python 3 (for the build architecture) for quite a while
> already.

It is possible that the build *and* host require python 3.4.

The reason being that when cross-testing glibc with the test-wrapper-env
script the build system may execute a command on the host system to 
run python (which is usually implemented as a ssh to a target system
with a shared mounted filesystem).

There are at least several pretty-printing tests which use python, and
require PExpect, and those run on the host during testing via the
test-wrapper-env abstraction.

I've started a new thread of discussion here, but in general my expectation
has always been that host and build environments need the same set of tools.

https://www.sourceware.org/ml/libc-alpha/2018-10/msg00395.html

> From a Debian cross bootstrap pov, no problems are to be expected.

OK.

> Daniel Schepler is working on a native bootstrap approach. As far as I
> understand, he natively bootstraps Debian from non-Debian (same
> processor architecure and kernel). I expect that his work will be
> impacted by the proposed change. I've added him to Cc to let him speak
> up.

Yes, in that case you must build a minimal python 3.4 for the host system.

> Requiring Python modules or extensions is another question. Some modules
> (e.g. six) are easy, but ones with dependencies of their own tend to not
> be. That's rooted in the way Debian handles cross architecture
> dependencies unfortunately.

Yes, we plan to limit the set of imports based on a small subset we need
for glibc.

> Thank you for reaching out in advance of the change and for relaying the
> message to non-subscribers.

You are welcome. This kind of change can be very disruptive, so I wanted
to get input from the distribution maintainers.

I'd like to get this resolved in a timely fashion so we can have an answer
for cleanups we'd like to do in glibc 2.29 (Feb 1, 2019 release). Having
an answer sooner makes the cleanup happen earlier and thus is safer overall
for distro testing.

-- 
Cheers,
Carlos.