Daniel P. Berrangé <berra...@redhat.com> writes: > On Tue, Feb 14, 2023 at 09:35:44AM +0100, Thomas Huth wrote: >> On 14/02/2023 08.40, Markus Armbruster wrote: >> > Daniel P. Berrangé <berra...@redhat.com> writes: >> > >> > [...] >> > >> > > We don't have to drop python 3.6. It is a choice because >> > > of a desire to be able to use some shiny new python >> > > features without caring about back compat. >> > >> > I read this on Friday, and decided to let it sit until after the >> > weekend. Well, it's now Tuesday, and to be frank, it's still as >> > offensively flippant as it was on Friday. It shows either ignorance of >> > or cavalier disregard for the sheer amount of work some of us have had >> > to put into keeping old versions of Python viable. >> >> I'm a complete python ignorant, too, so I'm a little bit surprised of the >> amount of pain that these scripts are causing. >> >> No matter of that fact, I think Peter still has a point that we have a real >> conflict here with our current support policy. So this either means that >> Python was the wrong choice for our needs (since it is moving too fast and >> causing too much friction), or we should really rethink our support policy. >> >> I guess we're too deep into the Python rabbit hole already, and I'm not >> aware of any other good solutions (back to Perl scripts? No, thanks!), so >> it's likely quite impossible to tune that knob. > > I still believe python is a probably the best thing for what we're using > it for. Certainly would not suggest shell or perl, and using a compiled > language would add its own complications for cross compilation. > >> Thus we should maybe really start talking about our support policy now. I >> think the main problem is likely the sentence "Support for the previous >> major version will be dropped 2 years after the new major version is >> released". Maybe we should shorten that time frame to 1 year. The 2 years
It's actually "2 years after the new major version is released or when the vendor itself drops support, whichever comes first." >> caused some confusions in the past already, since e.g. Debian only supports >> the previous major release for only one more year, and macOS also releases a >> major version each year ... so IMHO we could shorten the time frame for the >> previous major release to 1 year instead. People then could still continue >> building QEMU on CentOS 8, but they have to be aware that they might install >> other software like Sphinx manually if they want to continue using QEMU with >> docs there. What do you think? > > > I think perhaps the problem is not in the length of time defined by > our support policy, but rather that we're facing a rather different > reality to the one we've historically been used it, where distros > are no longer critical dependancies and our support policy does not > reflect that. > > > For any C/C++ application, wanting to target the versions shipped in a > distro has been pretty much normal practice. C has not ever come with > a standard package manager toolset, the distros service that role. The > distros also aren't generally a fan of shipping multiple versions of > C libs in parallel. > > > Pretty much every non-C library though is different. They all have > their own package manager service / tools (perl has cpan, pytyhon has > PyPi/pip, ruby has gems. With latest compiled languages like Go/Rust, > this has gone one step further and is natively integrated into the > compiler toolchain as standard. > > > IOW, for everything except C, it has become increasingly normal > practice to ignore the distro and dynamically download all the deps > your application needs into a self contained local environment. > Now, the distros aren't especially a fan of this new world, since > they still prefer to unbundle all these deps, but I think that > approach is increasingly difficult for them to achieve because the > majority of upstreams don't care for the distro versions. > > > Thus what we're experiancing is a clash between the traditional > way that C applications/libraries deal with their deps, vs the > way pretty much every other language deals with their deps in > the modern world. It has come up now because we're making much > more use of python now, than we did in the past. Yes. The traditional way of building applications is to examine the environment, and configure the application accordingly. If you depend on libfoo, configure looks for (a supported version of) libfoo, and the source code deals with differences between versions, if any. libfoo is expected to bend over backwards to avoid differences. The newfangled way of building applications is to set up a controlled environment. No need to configure the application. Pros and cons, no need to rehash them here, I believe. > Our support policy is written from the POV of the C world, and > merely reducing the length of time we support a distro does not > address the different world view of Python. > > Should we instead try to be more explicit about the different > needs of the non-C dependencies ? > > We could for example say > > * For native library/application dependancies we aim to > support the two most recent distro versions, for 2 years > overlap > > * For non-native library/applications dependancies we aim > to support only the most recent distro version. Users > of older distros may need to dynamically fetch newer > deps. Who does the fetching, users manually, or the build process automatically? > The python 3.8 runtime would be considered a native dep, so fall > under the 2 distro versions rule. This is fine with CentOS 8, > since it provides newer python runtime versions. > > The python libraries, or tools written in python (meson), would > fall under the second rule, and so only need to target one distro > version. This would be compatible with CentOS 8, as the users would > be expected to download extra python components (or we do it on > their behalf). > > For the second rule, rather than saying most recent distro versions, > possibly we might want to carve out an exclusion for LTS distros too. > ie, explicitly don't care about versions of non-native bits in RHEL > at all, beyond availability of the base (python) runtime. Interesting idea. Can anyone think of reasons not to do this?
