On Thu, Feb 16, 2023 at 02:08:33AM +0100, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > 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?
I expect both cases need supporting. In the case of distro builds, they will have to fetch the deps ahead of time, because the build environments usually won't have any network access. Some contributors have also previously objected to the build system fetching stuff off the network, but they're a small minority. For friendliness to developers, the build process would be best to fetch automatically, if they haven't been provided upfront. > > 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? It is probably even more compelling when looking at SLES, which is having an even larger gap between releases than RHEL does. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
