On Wed, Jun 21, 2017 at 10:25 PM, Nick Coghlan <ncoghlan@xxxxxxxxx> wrote: > 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) This is not necessary, as EPEL buildroot pulls it in automatically. > 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) EPEL and IUS are pretty easy, as you can use %python3_pkgversion for that. SCLs get pretty hard, because there's no particular guideline about how to build against SCLs to provide SCLized Python module packages. > 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) Distro conditional controls? I'm doing this now with one of the packages I'm working on now. > 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) > We'd need a slightly different way to do packaging for that. I'm not sure that'd be a good idea either. If they're using the unversioned stuff at the source, you can pretty easily use setuptools (or just sed it yourself) to set to a versioned runtime. This could be pretty automatic though the use of the unversioned macros (%py_build, %py_install, etc.). > 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). > Sure, I'm not saying we should change things for the fun of it. But the issue is that a lot of our packaging is a mess or just unnecessarily annoying/difficult, and that's not restricted to Python packaging. For example, Ruby packaging is mixed between ruby-<module>, rubygem-<module>, <module>, and doesn't really support versioned runtimes well, even though Ruby itself supports versioned runtimes (just like Python). PHP packaging is unnecessarily manual, in part because there's a dislike for automation there, so the Provides and Requires are all manually crafted, as well as the autoloader, which gets very tedious. While in the past the naming of packages was super inconsistent, it has mostly churned over to a standardized naming. The problem with our Python packaging is that we've never actually *tried* to enforce a standardized scheme, so it's pretty much "guess the package name" all the time. Is it Py<foo>? Is it python-<foo>? Is it py<foo>? Is it <foo>? Do we have py2 and py3 variants? Where are the binaries? Are they substitutable? It's pretty crazy... This mess makes it very hard to track dependencies and package new Python based things. Other distributions, like Mageia and openSUSE, have both taken the opportunity to explicitly fix this because while it sucks up front, the long term benefit of being able to reliably figure out what something is named is very, very, helpful. As a community, we need to take pride in that our packages are consistent, sane, and easy to build, find, identify, and use. A lot of times, it doesn't feel like we do... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
