Thomas Huth <th...@redhat.com> writes: > 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.
Thus the exception ... >> 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. ... right here: >> 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. > > And sure, you can argue that it's "just" the documentation. But IMHO that's > still an essential part of the QEMU build, and it used to work before, so it > feels wrong to cut that now out. And also, if we start with the > documentation now, what's next? If for example scripts/shaderinclude.py > stops working with Python 3.6, do we then simply say: "Oh, it's fine, you > can still build all the other targets that work without this script, just > not the ones anymore that need it"? My view on all this is a bit more pragmatic. For a human developer, the difference between "dnf install python-sphinx" and "pip install sphinx" is, in my opinion, close to negligible. Really no comparison to "git-clone GCC and bootstap it". You seem to disagree with that. For automated builds in general, and distro packaging in particular, the difference is real, and could even be a show stopper. But who's packaging bleeding edge QEMU on CentOS 8? I suspect the only automated builds are our own CI, where the difference is real, but hardly a show stopper. John's patch is the stupidest solution that could possibly work for us: disable doc building on CentOS 8. Alternative solutions have been proposed, and that's fair. Again, you seem to think this issue is a lot more serious. So maybe this breaks our support statement for a sufficiently rigid interpretation of our support statement. Not the way interpreted it, but if it's the way it is to be interpreted, I stand corrected. But then I'd like us to be a bit more pragmatic. Is minor and graceful degradation for systems close to the trailing edge really so unacceptably terrible that we have to bend over backwards to avoid it? >> All the angst about CentOS falling off the end of our "supported build >> platforms" list is not actually warranted by this series :) > > Using the term "angst" for the concerns of your fellows here is quite > cheeky. It's not about "angst", it's about a discussion that our support > policy might need to be adjusted if we do this step. So instead of writing > such sentences, I'd rather would like to see you posting a patch for > docs/about/build-platforms.rst for constructive further discussion instead. The phrasing of this sentence was ill-advised. If it caused offense, I apologize.