On 4 December 2014 at 23:10, Bohuslav Kabrda <bkabrda(a)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(a)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(a)gmail.com | Brisbane, Australia