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)
Change History (18)
comment:1 follow-up: 2 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 |
comment:2 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 follow-up: 4 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 follow-up: 5 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 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: | new → closed |
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 follow-ups: 11 12 Changed 13 years ago by mf2k (Frank Schima)
comment:11 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 Changed 13 years ago by lockhart (Thomas Lockhart)
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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)
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:15 Changed 12 years ago by jmroot (Joshua Root)
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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.