On 22 June 2017 at 12:54, Neal Gompa <ngompa13(a)gmail.com> wrote:
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.
Agreed, and in chatting to Miro Hroncok off-list, he clarified that
the core near term goal is to ensure that all "python-XYZ" names are
solely virtual provides declarations, with the actual RPMs themselves
being called "python2-XYZ". That then sets up a future combined switch
where (in combination with proposing some changes to the upstream
guidance in PEP 394):
* %python_provides switches to declaring "python-XYZ" as the Py3 version
* "/usr/bin/python" switches to running Python 3 by default
But that won't work without doing the preparatory working of cleaning
up Fedora's Python packages and ensuring consistency not only for new
Python packages, but also for existing ones. (I suspect a new
Taskotron task, or enhancements to an existing one like rpmgrill may
also help on that front)
So I'm largely in favour of the change (aside from a few relatively
minor technical quibbles), and am mainly advocating for some
improvements to the communications strategy around it that give
maintainers more specific directions regarding what they need to do,
rather than requiring them to figure out the necessary changes for
themselves by reading through the updated packaging policy and then
comparing it to their current spec files.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia