On Mon, Jan 19, 2009 at 6:26 PM, Ryan Schmidt <[email protected]> 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? _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
