Opened 13 years ago

Closed 12 years ago

#33241 closed update (fixed)

py-omniORBpy @ 3.6 new upstream version available

Reported by: lockhart (Thomas Lockhart) Owned by: stromnov (Andrey Stromnov)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc:
Port: py-omniORBpy

Description

Upstream omniORB and omniORBpy have versions 4.1.6 and 3.6 available. The omniORB port is currently being updated (#33226) to 4.1.6 and omniORBpy must use the matching version (3.6). The omniORB Portfile supports several variants for different versions of python, and istm that similar features could be available here. Will work on that pending feedback on the advisability of this.

Attachments (3)

Portfile.diff (2.5 KB) - added by lockhart (Thomas Lockhart) 13 years ago.
New patch using python subports. Tested for the case of python27 on Lion. Needs the corresponding version of omniORB (4.1.6) installed.
Portfile-svn-20120229.diff (1.7 KB) - added by lockhart (Thomas Lockhart) 13 years ago.
Patch to current svn Portfile to update back to 3.6 which is required to match 4.1.6 in the omniORB port.
Portfile (2.6 KB) - added by lockhart (Thomas Lockhart) 13 years ago.
Updated complete Portfile putting python libraries into /opt/local/Library/Frameworks/... rather than in /opt/local/lib/... since the latter is not on the MacPorts python search path. Also bump the revision number. Both omniORB and omniORBpy now run without needing paths set.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 13 years ago by mf2k (Frank Schima)

Cc: stromnov removed
Keywords: haspatch removed
Owner: changed from macports-tickets@… to stromnov@…
Version: 2.0.3

Trac requires complete email addresses in the Cc field.

This patch is not correct as it stands. You cannot switch to python 2.7 with a py-* port. This port is for python 2.4. Really it needs to be unified so all python versions are properly covered.

comment:2 in reply to:  1 Changed 13 years ago by lockhart (Thomas Lockhart)

Replying to macsforever2000@…:

Trac requires complete email addresses in the Cc field.

This patch is not correct as it stands. You cannot switch to python 2.7 with a py-* port. This port is for python 2.4. Really it needs to be unified so all python versions are properly covered.

This is exactly the feedback I'm looking for. Do you have an an example of what "properly covered" entails? Can I implement variants for 2.4 through 2.7 (the omniORB port does this)? I do know how to do those in principle, but would need to hardcode which variant should be the default for which version of Mac OS X and that seems clumsy and unsustainable. Can I detect what variant the (required) omniORB port was installed as and then use that in this one? Currently there are py25_omniORBpy and py26_omniORBpy as well as py_omniORBpy and generating py27_omniORBpy seems like the wrong way to go (if not, then maybe py_omniORBpy should be retired in favor of py24_omniORBpy. Ugh. But I can do a new py27_omniORBpy fairly easily if that is preferred. The biggest issue afaict is to keep py_omniORBpy in sync with omniORB, which can be built with various versions of python. Maybe if I provide variants then we can just have the default variant match the same default as for omniORB? Suggestions please!

comment:3 Changed 13 years ago by mf2k (Frank Schima)

Take a look at py-pil which is a "unified" python port using the python 1.0 portgroup and sub-ports to cover python versions 2.4, 2.5, 2.6, and 2.7. A unified version will make it much easier to keep everything in sync with omniORB because you only have to change a single portfile to cover all the python versions.

It would be nice to move all of the functionality of the omniORB python variants into py-omniORB port. Otherwise they would have to be installed correctly (e.g. omniORB +python27 and py27-omniORB) to not cause problems for users.

comment:4 in reply to:  3 ; Changed 13 years ago by lockhart (Thomas Lockhart)

Replying to macsforever2000@…:

Take a look at py-pil which is a "unified" python port using the python 1.0 portgroup and sub-ports to cover python versions 2.4, 2.5, 2.6, and 2.7. A unified version will make it much easier to keep everything in sync with omniORB because you only have to change a single portfile to cover all the python versions.

It would be nice to move all of the functionality of the omniORB python variants into py-omniORB port. Otherwise they would have to be installed correctly (e.g. omniORB +python27 and py27-omniORB) to not cause problems for users.

Grrr. The omniORB package also requires python so I started my testing there (it currently has a bunch of explicit variants with no apparent ability to choose "the default python installation" which the python portgroup seems to enable. Anyway, it seems that a port needs to live inside the python category for python subports to work. Any suggestions for how to enable those features in a devel/ package?

Changed 13 years ago by lockhart (Thomas Lockhart)

Attachment: Portfile.diff added

New patch using python subports. Tested for the case of python27 on Lion. Needs the corresponding version of omniORB (4.1.6) installed.

comment:5 in reply to:  4 Changed 13 years ago by lockhart (Thomas Lockhart)

Take a look at py-pil ... ... move all of the functionality of the omniORB python variants into py-omniORB port...

Anyway, it seems that a port needs to live inside the python category for python subports to work. Any suggestions for how to enable those features in a devel/ package?

Haven't yet worked out installing omniORB using a subports feature. But this seems to work fine for omniORBpy (after defeating the configure, make, and install defaults for the python mode) and have posted an updated patch. I can test with python27 on Lion and the installation works properly (tested with one of my projects which uses this package). I'd also like to put "haspatch" as a keyword but that does not seem to be available to me.

comment:6 Changed 13 years ago by mf2k (Frank Schima)

Keywords: haspatch added

comment:7 Changed 13 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: newclosed

r90041. Committed with minor adjustments.

comment:8 Changed 13 years ago by mf2k (Frank Schima)

omniORB port should also be updated in #33226. But I'm not clear if that's ready to go yet.

comment:9 Changed 13 years ago by mf2k (Frank Schima)

I can back down to version 3.4 in this unified port too.

comment:10 Changed 13 years ago by mf2k (Frank Schima)

OK, I reverted to version 3.4. r90042. r90043. r90044. Hopefully I beat the portindex. I can increase the epoch if not.

comment:11 in reply to:  10 Changed 13 years ago by lockhart (Thomas Lockhart)

Replying to macsforever2000@…:

OK, I reverted to version 3.4. r90042. r90043. r90044. Hopefully I beat the portindex. I can increase the epoch if not.

So what is the process for actually accomplishing an update to a new upstream version? omniORBpy 3.4 is 2.5 years old and omniORBpy 3.6 has been available for 6 months. I've got a submission in for omniORB which has been wedged by unresolved, nonspecific, untestable concerns from the old maintainer. Help!

comment:12 in reply to:  10 Changed 13 years ago by lockhart (Thomas Lockhart)

Resolution: fixed
Status: closedreopened

Replying to macsforever2000@…:

OK, I reverted to version 3.4. r90042. r90043. r90044. Hopefully I beat the portindex. I can increase the epoch if not.

pixilla suggested that I use the svn repository to fetch ports. Although it is not clear from the trac logs, the omniORB port update (issue #33226) does have 4.1.6 and the corresponding omniORBpy must be at 3.6 to be compatible. svn currently shows 3.4. I've updated the patch against the svn current state.

Changed 13 years ago by lockhart (Thomas Lockhart)

Attachment: Portfile-svn-20120229.diff added

Patch to current svn Portfile to update back to 3.6 which is required to match 4.1.6 in the omniORB port.

Changed 13 years ago by lockhart (Thomas Lockhart)

Attachment: Portfile added

Updated complete Portfile putting python libraries into /opt/local/Library/Frameworks/... rather than in /opt/local/lib/... since the latter is not on the MacPorts python search path. Also bump the revision number. Both omniORB and omniORBpy now run without needing paths set.

comment:13 Changed 12 years ago by lockhart (Thomas Lockhart)

Cc: lockhart@… added

Cc Me!

comment:14 Changed 12 years ago by lockhart (Thomas Lockhart)

Cc: lockhart@… removed

Cc Me!

comment:15 Changed 12 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.