interactions with /usr/local (was: error installing git-core ...)

[Stephen Bannasch]

At 5:24 PM -0500 8/21/07, Ryan Schmidt wrote:
>On Aug 21, 2007, at 16:49, Stephen Bannasch wrote:
>>Is there a better way to have code built from source in /usr/local and other code built with ports (that use some libraries in common) and not have them interact without temporarily renaming /usr/local?
>
>No... I recommend you have nothing directly in /usr/local. If possible, install that software with MacPorts as well. If no portfiles exist, you could write them and contribute them to the project. Portfiles are fairly easy to write. You can look at how the existing portfiles are written, or read the new manual that's being developed.

Thanks for responding Ryan.

Oh dear ... that's sounds like a bunch of work ... but I'll consider it.

Most of what I've got in /usr/local I could get through ports. I've got two basic questions:

1) If I install ruby with port will the ruby libraries I then install with ruby gems compile their native extensions correctly? This is a specific case of the more general issue where I use port to install an environment that then expects to be able to run it's own package management system and compile code using shared libraries.

2) When I am playing or working with some bleeding edge software checked out from a repository (Ruby 1.9, Rubinus, etc) normally it would normally be setup to install itself in /usr/local. Where would I install it instead?  This might be software that I regularly 'svn up' and make -- I don't assume I'd install it in /opt/local -- I assume that the software in that tree would only be managed through port.

I checked the wiki for information on my questions:

  http://trac.macosforge.org/projects/macports/wiki

In the FAQ page:

>Why is /opt/local the default install location for MacPorts?
>/opt/local was chosen so as to avoid stomping on other various installations (e.g. fink uses /sw to do the same); /usr/local is not a viable choice for several reasons:
>	1.	Some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed
>	2.	/usr/local is usually reserved for the given system's admin to install items local to that system, and tends to be a bad choice to have taken over by a non-system port system
>	3.	gcc considers /usr/local to be a standard system directory, causing (at least) the include directory to be unable to appear early in the list of include directories, and hence causing MacPorts-installed items to be difficult to use properly for items which need them (where another version is installed elsewhere, like /usr/X11R6)

I'm not sure exactly what #3 is saying but it sounds like it's related to the root problem about why port has problems with parallel libraries installed in /usr/local -- when port is using gcc to compile it's applications and libraries it can't tell gcc to ignore /usr/local.

I thought I'd read up on the issues but the link mentioned here:

>Some responses concerning /usr/local have been aired on the mailing list over time.

  http://www.opendarwin.org/pipermail/darwinports/2004-May/021190.html

Is a dead link -- I suppose I could use the Wayback Machine to find the thread ... sigh

Understanding these issues better might help me answer my second question.

Also the links to "Documentation" don't open ...? Example:

 http://www.darwinports.org/docs/ch03s05.html

Earlier I had installed specific versions of APR, SVN, SQLite, and the Python bindings in order to run Trac (not using port) an the Trac doc was very specific about compatible versions but this caveat worries me:

>Is it possible to have a dependency on a specific variant of another port? E.g. "postgresql8 +server"?
>No. The current state of the dependency engine is unable to handle specifying anything beyond "port X requires port Y" or "port X requires a file which can be provided by port Y." There have been discussions on revamping the engine (see the mailing list archives) but nothing concrete as yet. This is why the most useful variants really shouldn't be variants at all but rolled into the port itself.

There are two basic ways to answer my question about ruby installed with port. Install another copy of MacOS somewhere and try it ... or ... figure out what the ruby port does. I couldn't find much documentation in the wiki about how the portfiles themselves.

Where the best root for the documentation which would tell me where the ruby portfile is defined and how to interpret what it does?

I need Ruby 1.8.5-p12 installed because there are some serious bugs in 1.8.6. The only portfile listed for Ruby is 1.8.6. Can I make a local repository of portfiles and adapt the 1.8.6 portfile to install the version of 1.8.5 I need instead?

I'm sure this is possible but where is it documented?

When I built Ruby myself I used these parameters to config:

--prefix=/usr/local
--enable-pthread
--with-readline-dir=/usr/local
--enable-shared

I'd like to be able to see if the ruby portfile uses equivalent parameters (obviously readline would be pointed elsewhere.