Kevin Horton wrote: []
I agree 100% that the default behavior should be to not touch /usr/local. But, if I understand correctly, none of the Apple supplied software should be in /usr/local. This would only be other user installed software. If the fink team can't find a way to make Fink ignore /usr/local when building things, then an optional, user selectable behavior to automatically temporarily move /usr/local out of the way appears to be better than the current situation.
It seems a shame to throw out a potentially useful improvement purely on philosophical grounds. If this change truly could cause serious problems, then it is a bad idea. But let's at least discuss what those problems could be before we throw the idea out.
There is no simple solution to this problem. Maybe none at all.
Of course, if there were a compiler switch (customized specs or something) to ignore /usr/local/lib and /usr/local/include, it would help somewhat, but /usr/local is so deeply hardcoded in many configure scripts that it is virtually impossible to have it neglected.
So the idea remains to have an option to move it automatically out of the way during compilation. But as you noticed, there is the problem what to do when failures occur. Manual user intervention is then inevitable. It is also inevitable for another reason: Sometimes you *want* things from /usr/local, even during building of Fink packages, for example if you chose the system-tetex and system-ghostscript packages. In this case you need some things from /usr/local, but you need to avoid others. Almost impossible, even with manual intervention, and completely impossible automatically. You also may have to think about other users on the system who don't want to have the rug pulled from under their feet.
IMHO, since manual intervention is inevitable anyway, we have to leave this to the user.
But after the experience I had in the past two days, this can be very painful. I started out to install Fink on a rather fresh Xserve, installed system-tetex and system-ghostscript because some GW stuff was already installed, and started to worry only when things (libwmf for one) started to break. By then it was too late. I tried to remove some of the include files and libraries from /usr/local, but I found out that dozens of packages had already linked to libfreetype and libfontconfig in /usr/local and had even documented this crime in their libtool *.la files. There was no way to correct this afterwards.
I really had to remove /sw/ completely and restart from scratch with /usr/local out of the way (Note that /usr/local/include and /usr/local/lib do not suffice, there can also be things like fontconfig-config and freetype-config in /usr/local/bin).
I even had to give up on system-tetex and system-ghostscript and install Fink versions. In the end I had to move /usr/local out of the way for a whole day until the 300 or so packages I needed were installed. I just hoped that nobody else was trying to run ghostscript or something during that time.
To David's mentioning of questions of policy: There is another problem of policy here, namely that packages are supposed to build identically on different systems (even if there are a few exceptions to this rule). As I found out, there are really very many packages, basically all the gnome and qt stuff at least, that build differently if you have libfontconfig, libfreetype etc in /usr/local. So if you want to distribute the compiled debs to other users, you *must* move /usr/local out of the way while building packages.
-- Martin
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
