Re: [28120] trunk/dports/lang/python24/Portfile
Revision 28120 Author raimue@macports.org Date 2007-08-21 06:41:55 -0700 (Tue, 21 Aug 2007)
Log Message lang/python24: Don't install python binaries without version suffix. Use new python_select to choose your version.
Modified Paths • trunk/dports/lang/python24/Portfile
Diff
Modified: trunk/dports/lang/python24/Portfile (28119 => 28120) --- trunk/dports/lang/python24/Portfile 2007-08-21 13:40:27 UTC (rev 28119) +++ trunk/dports/lang/python24/Portfile 2007-08-21 13:41:55 UTC (rev 28120) @@ -93,6 +93,20 @@ } }
+ +# delete symlinks without version suffix, use python_select instead to choose version +platform darwin { + post-destroot { + cd ${destroot}${prefix} + file delete bin/python + file delete bin/pythonw + file delete bin/idle + file delete bin/pydoc + file delete bin/smtpd.py + file rename share/man/man1/python.1 share/man/man1/python2.4.1 + } +} + platform puredarwin { configure.args-delete --enable-framework=${prefix}/Library/Frameworks configure.args-append --disable-toolbox-glue --disable-framework
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/bin/python or with e.g. #!/usr/bin/env python. Maybe those ports using port:python24 should be patched to use "python2.4" instead ? --anders
On Aug 21, 2007, at 9:18 AM, Anders F Björklund wrote:
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/ bin/python or with e.g. #!/usr/bin/env python.
Maybe those ports using port:python24 should be patched to use "python2.4" instead ?
Ouch, I agree... Does "python-select" set a link to python24 or python25 ? If so, then things should work... ${prefix}/bin/python should be a link to the currently-selected Python. And of course ${prefix}/Frameworks/Python/Current should be set to point to the correct version, as well. - boyd Boyd Waters National Radio Astronomy Observatory Socorro, New Mexico
Boyd Waters wrote:
On Aug 21, 2007, at 9:18 AM, Anders F Björklund wrote:
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/bin/python or with e.g. #!/usr/bin/env python.
Maybe those ports using port:python24 should be patched to use "python2.4" instead ?
Ouch, I agree...
Does "python-select" set a link to python24 or python25 ?
If so, then things should work... ${prefix}/bin/python should be a link to the currently-selected Python.
And of course ${prefix}/Frameworks/Python/Current should be set to point to the correct version, as well.
I think we we should have separate Framework directories for each Python version, otherwise if you have 2.4 and 2.5 installed on your system, then the Current symlink will point to 2.5, presumably, and you won't be able to do a framework build against 2.4. I believe this is the case because the compile just specifies something like -F/opt/local/Library/Frameworks -framework Python So I suggest we change 2.4 and 2.5 to install the framework portion into $prefix/Library/Framework-Python2.4 and $prefix/Library/Framework-Python2.5 Regards, Blair -- Blair Zajac, Ph.D. <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
On Aug 21, 2007, at 11:01 AM, Blair Zajac wrote:
I think we we should have separate Framework directories for each Python version, otherwise if you have 2.4 and 2.5 installed on your system, then the Current symlink will point to 2.5, presumably, and you won't be able to do a framework build against 2.4.
I'm glad we're discussing this, but isn't the version issue exactly what the Framework structure is supposed to address? I will look into Framework/Versions and see if I can't suggest something better, but in any event I vote against multiple, top-level Python framework directories (such as Libarary/Frameworks/Python24). Regards, - boyd
Boyd Waters wrote:
On Aug 21, 2007, at 9:18 AM, Anders F Björklund wrote:
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/bin/python or with e.g. #!/usr/bin/env python.
Maybe those ports using port:python24 should be patched to use "python2.4" instead ?
Ouch, I agree...
Sorry, I didn't thought this change would make such problems. Maybe I should have started a discussion here before. Ports which are using the PortGroup python24 or python25 should just use ${python.bin} in their scripts.
Does "python-select" set a link to python24 or python25 ?
No, it defaults to the system provided python 2.3 since we can't know which version the user has installed and wants to use.
If so, then things should work... ${prefix}/bin/python should be a link to the currently-selected Python.
Yes, it is. But without python_select you don't have any symlink there...
And of course ${prefix}/Frameworks/Python/Current should be set to point to the correct version, as well.
Currently we don't have any other python frameworks than 2.4. Rainer
Boyd Waters wrote:
On Aug 21, 2007, at 11:01 AM, Blair Zajac wrote:
I think we we should have separate Framework directories for each Python version, otherwise if you have 2.4 and 2.5 installed on your system, then the Current symlink will point to 2.5, presumably, and you won't be able to do a framework build against 2.4.
I'm glad we're discussing this, but isn't the version issue exactly what the Framework structure is supposed to address?
I didn't see a way to tell the compiler to use an older version of an installed Framework.
I will look into Framework/Versions and see if I can't suggest something better, but in any event I vote against multiple, top-level Python framework directories (such as Libarary/Frameworks/Python24).
Well, if there's no way to have 2.4 and 2.5 installed at the same time and to have the compiler pick a specific version, then we'll have to use different top level framework directories. Blair
Rainer Müller wrote:
Boyd Waters wrote:
On Aug 21, 2007, at 9:18 AM, Anders F Björklund wrote:
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/bin/python or with e.g. #!/usr/bin/env python.
Maybe those ports using port:python24 should be patched to use "python2.4" instead ?
Ouch, I agree...
Sorry, I didn't thought this change would make such problems. Maybe I should have started a discussion here before.
Ports which are using the PortGroup python24 or python25 should just use ${python.bin} in their scripts.
Does "python-select" set a link to python24 or python25 ?
No, it defaults to the system provided python 2.3 since we can't know which version the user has installed and wants to use.
If so, then things should work... ${prefix}/bin/python should be a link to the currently-selected Python.
Yes, it is. But without python_select you don't have any symlink there...
And of course ${prefix}/Frameworks/Python/Current should be set to point to the correct version, as well.
Currently we don't have any other python frameworks than 2.4.
One of the issues with having a framework build for 2.5 is the framework coexistence issue. We would like to have 2.5, and I would like to have 2.4 and 2.5 installed at the same time and have framework installs for both. Blair
Boyd Waters wrote:
On Aug 21, 2007, at 9:18 AM, Anders F Björklund wrote:
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/bin/python or with e.g. #!/usr/bin/env python.
Maybe those ports using port:python24 should be patched to use "python2.4" instead ?
Ouch, I agree...
Does "python-select" set a link to python24 or python25 ?
If so, then things should work... ${prefix}/bin/python should be a link to the currently-selected Python.
And of course ${prefix}/Frameworks/Python/Current should be set to point to the correct version, as well.
Oh, I don't think python-select should change the Current symlink. You don't want the currently selected python-select to affect any successive compiles. For example, you could python-select to 2.5, but build a Port that is designed for 2.4, but it ends up linking against the 2.5 framework. Blair
+# delete symlinks without version suffix, use python_select instead to choose version +platform darwin { + post-destroot { + cd ${destroot}${prefix} + file delete bin/python + file delete bin/pythonw + file delete bin/idle + file delete bin/pydoc + file delete bin/smtpd.py + file rename share/man/man1/python.1 share/man/man1/python2.4.1 + } +} +
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/bin/python or with e.g. #!/usr/bin/env python.
The first couple of casualties of this change are starting to come in, people are building py-gtk (or something that depends on it) and find it is getting linked with Python 2.3. Since /opt/local/bin/python is now gone, configure will pick up /usr/bin/python instead and go from there... --anders
This change will break ports that depends on "python24" and then try to use the "python" binary, either directly with #!/opt/local/bin/python or with e.g. #!/usr/bin/env python.
The first couple of casualties of this change are starting to come in, people are building py-gtk (or something that depends on it) and find it is getting linked with Python 2.3. Since /opt/local/bin/python is now gone, configure will pick up /usr/bin/python instead and go from there...
I fixed an unrelated issue with python24/python25 (#12221, was calling /usr/local/bin/python) but left the revision untouched since I didn't want to break python24 for our old users - that priviledge is being reserved for new users. --anders
participants (4)
-
Anders F Björklund
-
Blair Zajac
-
Boyd Waters
-
Rainer Müller