Steps to ensure compatibility between fink and macports

[Shreevatsa R]

On Mon, Jan 19, 2009 at 6:26 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jan 19, 2009, at 10:01, Shreevatsa R wrote:
>
>> On Sat, Jan 17, 2009 at 3:58 AM, Ryan Schmidt wrote:
>>
>>> On Jan 17, 2009, at 01:12, David T. wrote:
>>>
>>>> Has anyone got a clear set of steps and guidelines for me to
>>>> follow to try using macports without messing up fink?
>>>
>>> Rename fink's /sw directory to something else. That should ensure it does
>>> not interfere with MacPorts.
>>>
>>> You should only use software installed via one package manager at a time
>>> --
>>> either Fink, or MacPorts, not both.
>>
>> Er, I don't think this is true. You don't have to do *anything* to
>> ensure Fink and MacPorts don't intefere with each other. They are both
>> designed to not interfere with the rest of the system, so if they do
>> interfere with each other, it's a bug in one of them.
>>
>> In my experience (and that of others) it works perfectly to use both
>> Fink and MacPorts simultaneously; installing packages from whichever
>> of the two happens to have a working version. (But do care about what
>> you do to your environment variables like $PATH: Fink's
>> /sw/bin/init.sh is a bit heavy-handed.)
>>
>> Of course I'm just a user and don't know very much of the internals of
>> either, so maybe someone can correct me if I'm wrong.
>
> 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
:-)]

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?