Re: [PATCH v2 0/7] Python: Drop support for Python 3.6

[Thomas Huth <thuth@redhat.com>]

On 20/02/2023 20.56, John Snow wrote:
> On Mon, Feb 20, 2023 at 1:16 AM Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 17/02/2023 21.46, John Snow wrote:
>>> On Thu, Feb 16, 2023 at 5:58 AM Thomas Huth <thuth@redhat.com> wrote:
>>>>
>>>> On 15/02/2023 20.05, Markus Armbruster wrote:
>>>>> The discussion under PATCH 6 makes me think there's a bit of confusion
>>>>> about the actual impact of dropping support for Python 3.6.  Possibly
>>>>> because it's spelled out in the commit message of PATCH 7.  Let me
>>>>> summarize it in one sentence:
>>>>>
>>>>>        *** All supported host systems continue to work ***
>>>>>
>>>>> Evidence: CI remains green.
>>>>
>>>> The CI remains green since one of the patches disabled the building of the
>>>> docs on CentOS 8. That's not how I'd describe "continue to work", at least
>>>> not in the same extend as before.
>>>>
>>>>> On some supported host systems, different packages need to be installed.
>>>>> On CentOS 8, for instance, we need to install Python 3.8.13 or 3.9.16
>>>>> instead of 3.6.8.  Let me stress again: same repository, different
>>>>> package.  No downsides I can see.
>>>>>
>>>>> The *one* exception is Sphinx on CentOS 8.  CentOS 8 does not ship a
>>>>> version of Sphinx that works with Python 3.7 or newer.  This series
>>>>> proposes to simply stop building the docs there, unless the user
>>>>> provides a suitable version of Sphinx (which is easy enough with pip).
>>>>
>>>> I think we've all understood that. The thing that you obviously did not
>>>> understood: This breaks our support statement.
>>>> I'm pretty sure that you could also build the whole QEMU suite successfully
>>>> on an ancient CentOS 7 or Ubuntu 18.04 system if you manually install a
>>>> newer version of GCC and some of the required libraries first. But that's
>>>> not how we understand our support statement.
>>>>
>>>> Sure, you can argue that you can use "pip install" to get a newer version of
>>>> Sphinx on RHEL 8 / CentOS 8 to continue building the docs there - but is
>>>> that really that much different from installing a newer version of GCC and
>>>> libraries on an ancient distro that we do not officially support anymore?
>>>> I'd say no. You also have to consider that not every build host has access
>>>> to the internet, maybe some companies only have an internal mirror of the
>>>> distro packages in their intranet (I remember some discussion about such a
>>>> case in the past) - so while you were perfectly fine to build the whole of
>>>> QEMU on a CentOS 8 there before this change, you could now not build parts
>>>> of QEMU anymore there due to the missing possibility to run "pip install"
>>>> without full internet connection.
>>>
>>> There are good points elsewhere in this thread and I am taking notes,
>>> but this critique caught my eye as something I was not specifically
>>> planning around, so I wanted to get an elaboration here if I may.
>>>
>>> Do we have a support statement for this? I find this critique somewhat
>>> surprising -- If we don't have internet, how did we get the other 20
>>> to 30 dependencies needed to build QEMU? To what extent are we
>>> *required* to preserve a build that works without internet access?
>>
>> It's not written in stone, but I saw it this way: If I have a complete
>> mirror of a distro repository in my intrAnet, I can use that mirror to set
>> up a QEMU build host system that has no access to the internet. Or maybe
>> think of a DVD image(s) with all distro packages that you use to install a
>> host without network access (and you copy the QEMU tarball there via USB
>> stick). I think it's not that uncommon to have such scenarios out there.
>>
>> For example, do you remember that SDL 1.2 discussion a some years ago? See:
>>
>>    https://www.mail-archive.com/qemu-devel@nongnu.org/msg631628.html
>>
>> It was not exactly the same situation, since those folks were even unable to
>> install a SDL2-devel package on their pre-installed hosts, though it was
>> theoretically available as an update in their distro, but I think it gives
>> an impression of what people are using and expecting out there... (and no,
>> I'm not happy with this, I'd also rather love if we could move faster in the
>> QEMU project sometimes).
>>
>>    Thomas
> 
> Well, in this case I believe our support policy generally is written
> to require a fully up-to-date version of the LTS distros, e.g. we
> don't really test against "release day" 16.04, in the same way we
> don't offer support for RHEL 8.0, just the latest point release.

Yes, sure, that's what I meant with "not exactly the same situation" ... it 
was just an example of people trying to compile QEMU offline.

> I think really all we need is the ability to know a priori what we
> need to build QEMU before going offline without any last second
> surprises during configure, make, or make check. Right?

I think it should be OK with the patch that Paolo suggested for the support 
policy and maybe a note somewhere that you have to make sure to install a 
newer Sphinx with pip in case you still want to build the docs on older 
enterprise distros...

  Thomas