Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1472330 - omniORB-devel: Provide a Python 3 subpackage
Summary: omniORB-devel: Provide a Python 3 subpackage
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: omniORB
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Haïkel Guémar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PYTHON3
TreeView+ depends on / blocked
 
Reported: 2017-07-18 13:17 UTC by Iryna Shcherbina
Modified: 2017-08-09 08:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-09 08:21:49 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Iryna Shcherbina 2017-07-18 13:17:18 UTC 
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 13:27:02 UTC 
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 14:05:53 UTC 
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 14:08:01 UTC 
> 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 14:28:01 UTC 
(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 14:30:29 UTC 
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 08:21:49 UTC 
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.