[Fedora-packaging] Changes in Guidelines Connected to "Python 3 as Default" Change

[Nick Coghlan]

On 4 December 2014 at 23:10, Bohuslav Kabrda <bkabrda at redhat.com> wrote:
> ----- Original Message -----
>> On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote:
>> >
>> > On 4 Dec 2014 00:38, "Bohuslav Kabrda" <bkabrda at redhat.com> wrote:
>> > > - (This is not really related to the switch, but more of a general
>> > > remark) In
>> > [4], it says that "python 3 version of the executable gains a python3-
>> > prefix".
>> > This is IMO bad, since upstream projects tend to name the versioned
>> > binaries
>> > "foo-3.4, foo-3" or "foo3.4, foo3". We should accept one of these - I'm not
>> > really certain which one of them. I tried to discuss this several times on
>> > distutils-sig mailing list, but without reaching a consensus. Either way,
>> > prefixing with python3- doesn't make sense to me, because it's not similar
>> > to
>> > any upstream way and you don't find the binaries under their names using
>> > tab
>> > completion (e.g. foo<tab> doesn't tell you about python3-foo).
>> >
>> > Agreed.
>> >
>> > CPython & pip use the "foo3.4, foo3" convention, so that seems enough of a
>> > reason to use that convention by default. We may want a "unless upstream
>> > does
>> > it differently" caveat though.
>> >
>> Second caveat here is that currently we use version suffixes to denote
>> a command coming from a compat package.  If we make this change we need to
>> address that as well.  So, you might have sphinx-build, sphinx-build-2,
>> sphinx-build-2.7, sphinx-build-3, and sphinx-build-3.4 for the python
>> interpreter.  If you need a forwards or backwards compat package you might
>> also have an 0.9 and 1.1 that you need to tack on.  Possible solution here:
>> use a "v" prefix for the compat package's version.  So if the default
>> package is 1.1, you would have the python-sphinx0.9 and python3-sphinx0.9
>> packages provide:
>>
>> * sphinx-build-v0.9
>> * sphinx-build-2-v0.9
>> * sphinx-build-2.7-v0.9
>> * sphinx-build-3-v0.9
>> * sphinx-build-3.7-v0.9
>
> I'd rather see sphinx-build-v0.9-3.4. IMO keeping the Python version at the very end in every case is better. In other words, the binary would normally be "sphinx-build-0.9" and we just append "-3.4" to it.
> Also, this makes me realize more arguments to append Python version with dash, not without it:
> 1) sphinx-build-v0.93.4 would be very confusing (I do understand that this is a downstream problem, but see the following point)
> 2) Similarly, if there is an upstream whose entry_point/script ends with a number (pep8 for example), it'd be highly confusing to use the notation without dash, it would yield pep83.4 assuming the upstream community would accept this scheme. This feels just wrong.

I think these are good reasons to default to using the dash if its
Fedora adding it. The guideline could be something like "For Python
executables, also provide symlinks with a '-X' and '-X.Y' suffix,
unless upstream already provides appropriately versioned executables
without the dash. For compatibility packages, the Python version is
appended *after* the specific package version".

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia