Steps to ensure compatibility between fink and macports

[David T.]

Thanks all for the discussion. Ryan-- the point is not that MacPorts (or Fink, for that matter) installs in random places; each installs in their own directory hierarchy (/sw for fink, /opt/local for MacPorts). The problems arise if a package in one realm links to a library in the other--especially if the library versions and features differ. Which explains why the safe route is to move the "other" directory while using the first one. Now I understand how to play with fire.

David

--- On Mon, 1/19/09, Shreevatsa R <shreevatsa.public at gmail.com> wrote:

> From: Shreevatsa R <shreevatsa.public at gmail.com>
> Subject: Re: Steps to ensure compatibility between fink and macports
> To: "Ryan Schmidt" <ryandesign at macports.org>
> Cc: sunfish62 at yahoo.com, "MacPorts Users" <macports-users at lists.macosforge.org>
> Date: Monday, January 19, 2009, 4:16 PM
> 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?