Steps to ensure compatibility between fink and macports

[Ryan Schmidt]

On Jan 19, 2009, at 18:16, Shreevatsa R wrote:

> On Mon, Jan 19, 2009 at 6:26 PM, Ryan Schmidt wrote:
>
>> There are software packages out there, for which we have ports in  
>> MacPorts,
>> that will, in an attempt to find the dependent libraries they  
>> need, always
>> look in /opt/local and /sw to find them. So if you have the same  
>> library
>> installed with both Fink and MacPorts, it's possible a MacPorts  
>> port will
>> link with the library from Fink, or the other way around. To  
>> prevent that,
>> we would have to know which software packages do this and patch  
>> them in
>> MacPorts to not do that. Since we do not know which software  
>> packages do
>> this, the safe course of action is to explain that it is not  
>> supported to
>> use Fink and MacPorts at the same time. "Not supported" means you  
>> can still
>> do it, but we will not necessarily help you with problems you  
>> encounter as a
>> result.
>
> I understand; that makes sense. It seems the same as the /usr/local
> problem again, with packages not being prevented from looking in
> places they shouldn't be looking, and potentially causing problems as
> a result. I guess it's worth investigating chroot and -nostdinc. The
> latter has been around since gcc 2.7.2.2 at least, which is more than
> 10 years old: it should be safe to use.
>
> [Technically, it should be considered a bug if a port isn't patched to
> prevent its looking in /sw. Some ports do handle this, e.g.
> http://trac.macports.org/browser/trunk/dports/net/pidgin/files/ 
> patch-configure.ac.diff
> :-)]

Probably. And you could file bugs against ports as you find them. But  
we might never find them all.

> Wrt the original question: I think MacPorts never installs anything
> outside /opt/local, so while a existing Fink installation can result
> in broken MacPorts ports, using MacPorts will not affect the
> functioning Fink installation itself. Is this correct?

I think that should be true, but of course I haven't tried it. But if  
a MacPorts port ever does write outside its intended area, it will  
print an error message to that effect.