On 22 June 2017 at 12:54, Neal Gompa <ngompa13@xxxxxxxxx> 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@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
