On Wed, Jul 02, 2025 at 03:24:09PM -0400, Paolo Bonzini wrote: > Il mar 24 giu 2025, 02:45 Markus Armbruster <arm...@redhat.com> ha scritto: > > > > ... I think I value this a bit higher than Markus, but not really > > because of offline builds. Rather, keeping the "accepted" key lower (i.e. > > supporting the packaged sphinx on a wide range of distros) makes it easier > > to bump the "installed" key when needed, as in this failure to run 5.3.0 > > under Python 3.13. > > > > Showing my ignorance again... I don't understand how keeping "accepted" > > lower helps. > > > > Because it makes it easier to use distro Python. If distro Python is > <accepted, configure's will try to use the "installed" version. If that > version in turn is too new for distro Python, you're screwed. So you want > to be as conservative as needed for accepted, but not more. > > Regarding fool or pioneer: for sure we're extraordinarily kind towards > distros. To some extent we have to do that because of 1) the possible > competition of other VMMs that completely ignore distros (e.g. because they > just use cargo)—packaging is an area where C still has an edge and we want > to keep that edge 2) we're an infrastructure component that can't just tell > users to grab a flatpak. > > The distro policy (mostly conceived by Dan) has served us well, with only > small adjustments needed to have newish version of Meson/Rust(*), and > non-prehistoric versions of Python. I don't see a need to change it, since > at this point we have the tools needed to manage the complexity.
Note that much of the commentary about distros versions has been in relation to the distro packagers, but that was not my only target in writing the distro policy. It was equally aimed at contributors using such distros, as well as 3rd party vendors building solutions on top of designated distro versions You can say contributors should just pick newer containers for their build env, or manually download newer deps, or have QEMU build fancy scripts to auto-download newer deps. All of those options have a cost to them, as compared to using what is already present in the distro. In terms of 3rd party vendors, they can have similar roles to a distro vendor, but are more likely to package up newer QEMU versions to run on pre-existing distros. A further goal of the support policy was to provide a mechanism to eliminate exactly these kind of mail threads. Before we had the policy, every single time someone wanted to bump the min version of any dep we would have debates over whether it was OK or not, there was always someone who wanted the old version of the distro forever. Defining the policy has allowed us to unconditionally bump the min versions of our times on a usually reasonable timeframe, without needing to engage in debate. We can just point people to our support policy when they complained that they really wanted old versions X, Y, & Z. Every time we make an exception to the policy, we undermine the benefits we obtain from it, taking us back the old world where our min versions were an inconsistent & arbitrary set, with little clear understanding of when we would change, either by maintainers or users. 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 :|
