On 21 June 2017 at 13:01, Neal Gompa <ngompa13(a)gmail.com> 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(a)gmail.com | Brisbane, Australia