moving "macports1.0" to ${prefix}
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ? If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0 --anders
Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
+1. I do this by hand with configure's --with-tclpackage option so I can have multiple MacPorts installed. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Blair Zajac wrote:
Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
+1.
+1 also from me.
I do this by hand with configure's --with-tclpackage option so I can have multiple MacPorts installed.
Regards, Blair
Same for me. This would be real a good improvement and make (as already said) multiple installations much simpler, which is usefull for maintainers and developers. Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGxHTrYRX4BO+zMikRCqZpAJ4iJyVUepNxgZmee/KM8Ec/V392NgCeP+3k J1ld1GZi/zSi1Iz+stkfEAc= =nOxb -----END PGP SIGNATURE-----
+1 from me, FWIW... I've made my MacPorts completely self-contained and this helps. (Along the same lines, I've changed all my Python ports to install under ${prefix}/lib, and other things to install under ${prefix}/ Applications -- multiple, parallel binary distributions are required and we keep *everything* installed by our MacPorts under a *single* directory tree.) - boyd Boyd Waters National Radio Astronomy Observatory Socorro, New Mexico On Aug 16, 2007, at 3:15 AM, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. / Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0
--anders
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. / Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports in /Library/Tcl/macports1.0 was to support "inferior" software that needs to be able to find the system's macports installation, regardless of ${prefix}. There's always --with-tclpackage, so people can do this manually if they need to. -landonf
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports in /Library/Tcl/macports1.0 was to support "inferior" software that needs to be able to find the system's macports installation, regardless of ${prefix}.
What software is this? The use case for having multiple MacPorts is fairly common. We have three +1's for making the change. Should we have a vote? Regards, Blair
On Aug 16, 2007, at 10:55, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/share/macports/ Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports in /Library/Tcl/macports1.0 was to support "inferior" software that needs to be able to find the system's macports installation, regardless of ${prefix}.
What software is this?
Any third party tool that rightfully expects "package require macports" to work.
The use case for having multiple MacPorts is fairly common.
Amongst developers. Not users. Most users have one installation of MacPorts.
We have three +1's for making the change. Should we have a vote?
Because direct democracy is the best method for making technical decisions? -landonf
Landon Fuller wrote:
On Aug 16, 2007, at 10:55, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports in /Library/Tcl/macports1.0 was to support "inferior" software that needs to be able to find the system's macports installation, regardless of ${prefix}.
What software is this?
Any third party tool that rightfully expects "package require macports" to work.
I'm just trying to get a sense of what we're talking about here, as we're discussing trade offs between competing concerns. How many tools are out there? I haven't used any of them, what are their names? How does that third party software even work if I do a --with-tclpackage? Does it break? What about getting the third-party software to work with multiple MacPorts installs? How does that work? It sounds like the third-party software should grow support to handle multiple MacPorts installs and the ability to point it at the root of an install and be able to find the TCL files it needs. Right now with --with-tclpackage, if everybody puts them into their own path under $prefix, then there's almost no hope for the third-party software. If we standardize on a location in $prefix, then the user can point the software at a MacPorts install and except it to work. So one remaining issue is how to get the third-party software to easily pick up the TCL files from a MacPorts install. It could check for a default location in /opt/local. Maybe use an environmental variable MACPORTS_HOME.
The use case for having multiple MacPorts is fairly common.
Amongst developers. Not users. Most users have one installation of MacPorts.
We have three +1's for making the change. Should we have a vote?
Because direct democracy is the best method for making technical decisions?
We have votes in the Subversion project on technical discussions, nothing new there. Regards, Blair
On Aug 16, 2007, at 11:10, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 10:55, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/ share/macports/Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports in /Library/Tcl/macports1.0 was to support "inferior" software that needs to be able to find the system's macports installation, regardless of ${prefix}.
What software is this? Any third party tool that rightfully expects "package require macports" to work.
I'm just trying to get a sense of what we're talking about here, as we're discussing trade offs between competing concerns.
OK, then I'll simplify. Arguments For Moving: Developers can install multiple versions without passing --with- tclpackage to configure (but they still have to pass a custom -- prefix to configure) Arguments Against Moving: Placing the Tcl package in the standard Tcl package directory means that external tools can find the system MacPorts library out of the box. It seems to me like developers already have an easily solution to their problem. -landonf
Landon Fuller wrote:
On Aug 16, 2007, at 11:10, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 10:55, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports in /Library/Tcl/macports1.0 was to support "inferior" software that needs to be able to find the system's macports installation, regardless of ${prefix}.
What software is this? Any third party tool that rightfully expects "package require macports" to work.
I'm just trying to get a sense of what we're talking about here, as we're discussing trade offs between competing concerns.
OK, then I'll simplify.
Arguments For Moving: Developers can install multiple versions without passing --with-tclpackage to configure (but they still have to pass a custom --prefix to configure)
Arguments Against Moving: Placing the Tcl package in the standard Tcl package directory means that external tools can find the system MacPorts library out of the box.
It seems to me like developers already have an easily solution to their problem.
-landonf
I got these points. Can you address the rest of the questions I asked in the previous note? That'll provide more context to make a choice. Thanks, Blair
On Aug 16, 2007, at 12:10, Blair Zajac wrote:
I'm just trying to get a sense of what we're talking about here, as we're discussing trade offs between competing concerns. OK, then I'll simplify. Arguments For Moving: Developers can install multiple versions without passing -- with-tclpackage to configure (but they still have to pass a custom --prefix to configure) Arguments Against Moving: Placing the Tcl package in the standard Tcl package directory means that external tools can find the system MacPorts library out of the box. It seems to me like developers already have an easily solution to their problem. -landonf
I got these points.
Can you address the rest of the questions I asked in the previous note? That'll provide more context to make a choice.
How many tools are out there? I haven't used any of them, what are their names?
Don't know. How many tools and custom code out there uses zlib? The choice was originally made to support the GUI PortsManager app. I think it was a good choice.
How does that third party software even work if I do a --with- tclpackage? Does it break?
It would break unless the author endeavoured to support your non- standard Tcl package installation.
What about getting the third-party software to work with multiple MacPorts installs? How does that work?
See answer above.
It sounds like the third-party software should grow support to handle multiple MacPorts installs and the ability to point it at the root of an install and be able to find the TCL files it needs.
Except that nobody, other than developers, will be running multiple MacPorts installations. You're taking a simple fix to a simple problem: - Install MacPorts in the standard Tcl library directory, where external software can access it. And proposing a complex fix for a non-existent problem: Developers don't have to type an extra --with-tclpackage, and users have to set MACPORTS_HOME and tell any external software where to find the MacPorts installation I hold that this is an entirely aesthetically-driven bike shed. Unless there's a *really good reason* to change something, why don't we just leave it, and the original logic behind it, alone?
Right now with --with-tclpackage, if everybody puts them into their own path under $prefix, then there's almost no hope for the third- party software. If we standardize on a location in $prefix, then the user can point the software at a MacPorts install and except it to work.
So one remaining issue is how to get the third-party software to easily pick up the TCL files from a MacPorts install. It could check for a default location in /opt/local. Maybe use an environmental variable MACPORTS_HOME.
Setting environmental variables in the GUI is beyond the scope of most user's needs.
Landon Fuller wrote:
The choice was originally made to support the GUI PortsManager app. I think it was a good choice.
I keeping the default of /Library/Tcl/macports1.0 is enough bring the GUI PortsManager.app back to life in good working order, then by all means keep the current location of @TCL_PACKAGE_DIR@ :-) I don't understand why the external software couldn't just look for the module in /opt/local, if indeed nobody has no more than installation and never move it, but maybe it is indeed harder to do...
Except that nobody, other than developers, will be running multiple MacPorts installations. You're taking a simple fix to a simple problem: - Install MacPorts in the standard Tcl library directory, where external software can access it.
This is the current default, so if that's the best then do nothing / keep it. As noted, those who want it moved can do so either using configure or after the installation. For the record, here are the default locations: Darwin: /Library/Tcl/macports1.0 FreeBSD: /usr/local/lib/tcl8.4/macports1.0 Linux: /usr/share/tcl8.4/macports1.0
I hold that this is an entirely aesthetically-driven bike shed. Unless there's a *really good reason* to change something, why don't we just leave it, and the original logic behind it, alone?
The main reason it was moved was to support packaging solutions (on other platforms) that only supported installing things in the designated prefix (e.g. /opt/local) and not in system directories (without choosing / as the root of the install, and supplying both the pats in full). But it was *only* during this packaging process, and it was restored into the system location by the use of a install script and similarly removed again from there with a uninstall script. It doesn't have to affect the standard install location unless we want it to, it was just an idea... --anders PS. But for those that *do* keep it in their ${prefix}, I would suggest having it located at ${prefix}/share/macports/Tcl so the location mayhem can be kept to a minimum... :-)
participants (5)
-
Anders F Björklund
-
Blair Zajac
-
Boyd Waters
-
Landon Fuller
-
Simon Ruderich