Bug 1472330

Summary:	omniORB-devel: Provide a Python 3 subpackage
Product:	[Fedora] Fedora	Reporter:	Iryna Shcherbina <ishcherb>
Component:	omniORB	Assignee:	Haïkel Guémar <karlthered>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	karlthered, manisandro
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-09 08:21:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1285816

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