On 21 June 2017 at 13:01, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > If we constrain ourselves to RHEL, then we're screwed until at least > 2024. I personally do not see this as a strong enough reason to not > fix our Python packaging globally. If anything, this should be an > incentive for Red Hat engineers to actually fix their Python packages > to match Fedora or at least have the necessary provides the shim both > ways. > > One thing I've observed as our biggest failing is that we do a very > bad job of actually rationalizing our own packages to match our > guidelines, for spurious reasons like this, where mistakes that make > it to RHEL dog us in Fedora forever. That's not only dumb, it's > dangerous, as it makes it very hard for us to make our distribution > better and more consistent. While I mostly agree with this, it's also important to take individual priorities and incentives into account when making mass policy changes on a volunteer-driven project like Fedora: we're effectively asking people to do additional work for free, and if we can't come up with a compelling justification for how the change will help them *personally*, then it's understandable that a lot of folks will put off dealing with the request indefinitely. For this specific change, that means we need to account for the fact in a lot of cases, folks are using Fedora for development, but then deploying to platforms like RHEL and CentOS, and this is most clearly evident when they're maintaining both Fedora and EPEL versions of their package (anyone), or Fedora and RHEL versions (Red Hatters). Given that we know there are going to be a lot of folks in that situation, it makes sense to do the relevant design work *up front*, and give concrete guidance on: 1. How to modify a package to explicitly declare it as "Python 2 only" (and the need for a "BuildRequires: epel-rpm-macros" to reliably get access to the versioned Python macros on EL systems) 2. How to modify a package to explicitly declare it as "Python 3 only" (and rely on SCLS, EPEL, or IUS to run on EL systems) 3. How to modify a package to explicitly declare it as "adapts to the preferred Python" (i.e. running in Python 3 on Fedora and Python 2 on EL systems) 4. How to modify a package to explicitly declare it as "runs in the default Python" (i.e. runs wherever `%python_provides` and `/usr/bin/python` point to) The first 3 cases are relatively straightforward (and covered by the current packaging policy), so it's mainly that 4th case that's currently at issue - the packaging policy says it's not allowed, even though it's at least arguably the most future-proof way to design a spec file (and definitely the easiest variant to keep consistent across OS versions at a spec file level). Cheers, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
