On Jul 29, 2010, at 17:25, Mark Farnell wrote: > So would it be a good idea to force *all* ports to be relocatable? > (i.e. only hardcode path relative to base path, *not* absolute path) > Will this be difficult to be enforced by a lintian-like tool?
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 dragging . > I think MacPort is mainly for user programs and libraries. Admin > tools such as daemons and OS maintenance (such as stuff in /bin and > /sbin) should have already been in the OS X itself rather than in > MacPort. That's not a correct assumption. Mac OS X does come with a lot of 3rd-party software, but there will always be new programs that are not part of the OS that users do not want to wait years for Apple to begin to include with the OS, or newer versions of software that Apple does include. For example, PHP was not part of Mac OS X until Leopard, so on Tiger, users used MacPorts to install PHP in order to have PHP at all. Now that PHP is part of Mac OS X some users are happy with that version, but others want more options than Apple provides, and/or want a newer version than the one Apple provides, so they still use MacPorts to install it. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
