selfupdate and readline support

[Shreevatsa R]

On Wed, Jan 14, 2009 at 03:40:10AM +1100, Joshua Root wrote:
> Shreevatsa R wrote:
> > The proper solution is for MacPorts to figure out a way of preventing
> > its ports from looking outside ${prefix} -- whether /usr/local or /usr
> > or any directory at all.
> 
> Unless you have a patch ready that fixes the problem The Right Way, I
> don't see how informing users of the problem is a bad thing.

Agreed that informing users of the problem is a good thing. Was only
objecting to the idea that "they are doing things they should not", when
it is actually MacPorts that is doing something that it should not, by
allowing its ports to use libraries outside its prefix.

On Tue, Jan 13, 2009 at 12:27:05PM -0500, robert delius royar wrote:
> Try `grep -R /usr/local /opt/local` just to see how many Macports  
> reference files in /usr/local.  If you install Macports gcc, I suspect  
> even that tool searches /usr/local/include and /usr/local/lib.  The auto 
> tools used to install with /usr/local as the preferred place to look for 
> configuration files, headers, and libraries.  I haven't checked  
> recently, but I suspect that is still the case.

Yes, autotools looks in /usr/local by default, and it can be pretty hard to
track down all instances and change this. That's why I said that it's not
reasonable to expect that users will be able to avoid having anything
installed in /usr/local at all.

>> The proper solution is for MacPorts to figure out a way of preventing
>> its ports from looking outside ${prefix} -- whether /usr/local or /usr
>> or any directory at all.
>
> It is probably not practical, but if ports were each to run a recursive  
> sed on source trees to change all references to '/usr/local/' from that  
> to '/opt/local', you might get some safety from the /usr/local  
> pollution.

That might change quite a few things unintentionally, and leave some
things unchanged. Another crude approach might be what is mentioned in
#15077,  "to rename it (e.g. to /usr/local-off), clean the affected port,
and [perform] the installation".

I do not know enough about this, but the right approach might be for
everything to be built in a chroot-ed environment, where /usr/local (and
other directories outside /opt/local) are not visible or available.
I think some other package management systems do something like this,
but I'm not sure.