-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 11/25/2015 09:20 AM, Juan Orti Alcaine wrote:

2015-11-25 14:34 GMT+01:00 Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com>:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 11/25/2015 07:16 AM, Juan Orti Alcaine wrote:

...

Hi,

I'm reading the guidelines about the naming of conflicting python2/python3 binaries [1], and I have doubts about if it is up to date. It says: "The unversioned executable must be the python2 version.", is this still true? In the example shown some lines before, the unversioned binary goes to the python3 package.

IIRC, this is specific to tools for python itself. So things like /usr/bin/python and /usr/bin/easy_install must be the python 2 version. For end-user packages, the current policy for F22+ is that they must be the python 3 version.

​Ok, thanks. It's not clear from reading the policy.

After a discussion with Toshio on IRC, I realize that I failed to clarify an important point:

This part of the policy is only important if you *must* ship binaries for both python 2 and python 3. In most cases (for end-user applications), this is not the case. You should only ship different versions of the binary if they are truly version-specific (such as the easy_install example, where the two versions need to operate ON python rather than just consuming python).

If your app is capable of running the same way under both Python 2 and Python 3, Fedora's policy is that you should ship *only* the python 3 version of the executable (so that they don't conflict). If your app must ship a binary for both, then they should follow the versioning rules you mentioned and the unversioned package should be the python 2 version.

Perhaps it would be better if you provided your specific example case so we can help you make the right choice here, rather than me trying to speak in broad generalizations.

On Wed, Nov 25, 2015 at 9:36 AM, Jeremy McMillan jeremy.mcmillan@gmail.com wrote:

Yes, please make the unversioned binary the default version required by system utilities. Python 2 should be relegated to special case use where library dependencies cannot be made to work under Python 3. This should probably be made explicit in release notes and documentation.

This is not a good thing to do. If there's only a single script needed then it should use python3 but if there's two versions of the script needed, then backwards compatibility concerns come into play. Upstreams that anticipate this thus far have been making the python3 version the suffixed version and the python2 version the unsuffixed. Our past practices are also to create the python2 version as the unsuffixed version and the python3 version as the suffixed one. between these, it is not good for people's expectations when they type a command or when they run their script to mess with what the unsuffixed version will end up invoking.

Follow the Guidelines -- in the current larger python ecosystem they are correct to specify that the unsuffixed binary should be the python2 version if both a python2 and python3 version is needed.

-Toshio

On Nov 25, 2015 6:16 AM, "Juan Orti Alcaine" j.orti.alcaine@gmail.com wrote:

...

Hi,

I'm reading the guidelines about the naming of conflicting python2/python3 binaries [1], and I have doubts about if it is up to date. It says: "The unversioned executable must be the python2 version.", is this still true? In the example shown some lines before, the unversioned binary goes to the python3 package.

With python3 as the default I guess the unversioned binary should be the python3 one.

[1] https://fedoraproject.org/wiki/Packaging:Python#Naming

-- Juan Orti https://apuntesderootblog.wordpress.com/ -- packaging mailing list packaging@lists.fedoraproject.org

http://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org

-- packaging mailing list packaging@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org