Bug 1472330 - omniORB-devel: Provide a Python 3 subpackage
omniORB-devel: Provide a Python 3 subpackage
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: omniORB (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Haïkel Guémar
Fedora Extras Quality Assurance
:
Depends On:
Blocks: PYTHON3
  Show dependency treegraph
 
Reported: 2017-07-18 09:17 EDT by Iryna Shcherbina
Modified: 2017-08-09 04:21 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-09 04:21:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Iryna Shcherbina 2017-07-18 09:17:18 EDT
Upstream, this software supports Python 3 starting version 4.2.0 [0]. 
Please provide a Python 3 package for Fedora.


According to the Python packaging guidelines [1], software must be
packaged for Python 3 if upstream supports it.
The guidelines give detailed information on how to do this, and even
provide an example spec file [2].

The current best practice is to provide subpackages for the two Python
versions (called "Common SRPM" in the guidelines). Alternatively, if
nothing depends on your Python2 package, you can just switch to Python 3
entirely.

It's OK to do this in Rawhide only, however, it would be greatly
appreciated if you could push it to Fedora 25 as well.


If you need more instructions, a guide for porting Python-based RPMs is
available at [3].
If anything is unclear, or if you need any kind of assistance with the
porting, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!

[0] https://sourceforge.net/p/omniorb/svn/HEAD/tree/branches/4_2/omniORB/ReleaseNotes.txt#l63
[1] https://fedoraproject.org/wiki/Packaging:Python
[2] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
[3] http://python-rpm-porting.readthedocs.io/
Comment 1 Sandro Mani 2017-07-18 09:27:02 EDT
I actually looked at this, but I'm not sure how to deal with the 

/usr/bin/omniidl
/usr/bin/omniidlrun.py

python scripts.

One approach I see is an unversioned /usr/bin/python in the shebang, so that the default interpreter is picked unless the user explicitly picks the interpreter, and then having -devel-python2 and -devel-python3 co-own the files.

Happy to hear other suggestions.
Comment 2 Iryna Shcherbina 2017-07-18 10:05:53 EDT
Upstream provides different versions of those files for Python 2 and Python 3. So if you choose to build python2-omniORB-devel and  python3-omniORB-devel, I believe you should follow the common practice and provide a versioned binary for Python 3 package, e.g. /usr/bin/omniidl-3

Also, if the binaries provide the same functionality across both Python versions, then you may package only the Py3 ones (see more in Fedora Packaging Guidelines for Python [0]).

[1] https://fedoraproject.org/wiki/Packaging:Python#Avoiding_collisions_between_the_python_2_and_python_3_stacks
Comment 3 Sandro Mani 2017-07-18 10:08:01 EDT
> Upstream provides different versions of those files for Python 2 and Python 3
Uhm, can you give a reference to that?

omniidl for one is the IDL compiler so easily called by other tools, hence I'd assume that the name should be changed.
Comment 4 Iryna Shcherbina 2017-07-18 10:28:01 EDT
(In reply to Sandro Mani from comment #3)
> > Upstream provides different versions of those files for Python 2 and Python 3
> Uhm, can you give a reference to that?

Sure. 
Python 3 version:
https://sourceforge.net/p/omniorb/svn/HEAD/tree/branches/4_2/omniORB/src/tool/omniidl/python3/scripts/omniidl.in

Python2 version:
https://sourceforge.net/p/omniorb/svn/HEAD/tree/branches/4_2/omniORB/src/tool/omniidl/python/scripts/omniidl.in

Correct me if I am wrong.
Comment 5 Sandro Mani 2017-07-18 10:30:29 EDT
Ok, but both are installed as /usr/bin/omniidl, i.e. the name collision is my issue here.
Comment 6 Sandro Mani 2017-08-09 04:21:49 EDT
Done in omniORB-4.2.2-4.fc27

Note You need to log in before you can comment on or make changes to this bug.