On Jul 29, 2010, at 4:42 PM, Ryan Schmidt wrote: > I think it would be a Herculean effort to go through all 7200+ ports that we > have to make sure they're relocatable. It would take years. I think I can > speak for most of us when I say we're not going to do that. If you or someone > wants to do that you could certainly begin the process, but I have better > things to do with my time. > > There might be a way to shortcut the process and make it separate from the > MacPorts build and install process, and rather part of the hypothetical > future binary packaging process. As has been said, install_name_tool can > usually be used to fix binaries to use libraries from whatever prefix is > desired; a script could identify all binaries in a port and automatically fix > the prefix of all of them. Another search could identify other files that > have the prefix in them and do the equivalent of a reinplace, in the hope > that the files are texty files and won't be corrupted by such an action. This > type of process could incidentally also be made part of the installer package > postflight script to allow MacPorts itself to be installed into any prefix > via the installer. Note that all of the preceding in this paragraph is about > one-time relocation at install time; it's not about true relocation that > would allow the user to move a program anywhere they wanted at any time > simply by draggi ng
Not sure if it matters, but to be honest, the way things are now is fine. If you desire to go outside of the default prefix then you go to the source. I believe I can remember perhaps three cases in which someone on the list mentioned MacPorts was in and alternate prefix, one of those was a core dev, which is understandable. Can one symblink /opt/local to elsewhere? Would that achieve the same? You could setFile the symblink invisible too. I like the installer, one click, does it's thing, and you don't have to think about it. I mean no offense by the following at all, none to any of the participants in this thread, or the OP of the thread... This much discussion would be better focused on the Apache2 layout in all honesty. MAMP is a core to MacPorts, MAMP is what brings many people to the project. Those people are not going to care where MacPorts lives, they want `sudo port install MAMP`. Look at the what, 30+ threads from two users today who went through a lot of pain to get MAMP in place. I am not sure why it was such an issue; but it shouldn't be, is my point, I think :) I would love to focus on what 9 out of 10 people are interested in, not the 2 out of 10, in which case, those 2 out of 10 usually know and understand how to get what they want by going to source anyway. /.02 -- Scott (* For off-list contact, replace talklists@ with scott@ *) _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
