On 12/04/2014 01:03 AM, Barry Warsaw 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).
In general, we don't provide two versions of the binaries. You won't find a
tox and tox-3 in /usr/bin. If we can provide a Python 3 version, and the
package maintainer has switched over, you'll only find the Python 3 version.
Users generally don't care what version Python their app runs on.
There are a few exceptions, but these are limited to cases where it actually
matters which version of Python the script runs. An example of this is nose
and nose2. Because these invoke different Python executable environments, the
shebang of these scripts does matter. E.g, we provide /usr/bin/nosetests
(#!/usr/bin/python), /usr/bin/nosetests-2.7 (#!/usr/bin/python2.7),
/usr/bin/nosetests3 (#!/usr/bin/python3). (Looks like we're missing one for
3.4, oh well.)
In these cases, the naming convention can get tricky. Usually, as you
suggest, the unversioned script is the Python 2 version, specifically
#!/usr/bin/python (or less commonly #!/usr/bin/python2 for PEP 394
aficionados). foo-2.7 will be #!/usr/bin/python2.7 (we don't support anything
older than that). foo-3 will be #!/usr/bin/python3 and foo-3.4 will be
#!/usr/bin/python3.4. As you can see for nosetests-under-Python-3, we're not
always consistent.
Of course it gets a little trickier for things like nose2. nose2-3 is
#!/usr/bin/python3.
+1
E.g.:
package "dnf" now use python2 and there exists package "python3-dnf". My common sense expects that in Fedora 22 "dnf"
would start using python3 and will obsolete "python3-dnf". And if it makes sense for maintainer, new subpackage
python2-dnf" will be created to support legacy layered applications.
Of course this is only for application, which want to support both pythons. For example package "mock" runs on python2
in Fedora21, but the same package "mock" runs on python3 in Fedora22 (because in Fedora 22 python3 should be default).
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
