Tales of the Raccoon Fink

So there's this big thread on the Apple SciTech list about Fink which seems to be complaining about a number of things that are either design features that people don't understand, or outright FUD about things that Fink supposedly breaks that has nothing to do with Fink.

For example, in this post, he says:

There's nothing wrong with linking against Fink libraries. If you want to include them in your own project, you can use install_name_tool to relocate the library for use in your own projects so that you don't need to work with the /sw directory yourself. The problem happens when you don't do this (e.g. Virex installing libs in /sw!). This is not Fink's problem, this is a problem with not understanding the Mac OS X development environment, and how library paths work on Darwin.

If you can't just move the libraries because the software you're using from Fink relies on other support files (config files and such), you can still take advantage of the porting work we've done by using our patches and building from source yourself. Our goal is to make it easier for people to run traditional UNIX software on the Mac. We understand that not everyone wants the full Fink infrastructure, which is why everything we do is available in "source" form, as a patch, and an info file that you can examine to see how the porting was done. No one is locking you into using Fink, Fink is a convenience.

There were also a number of posts about /usr/local. There are a couple of very good reason Fink (or any other 3rd-party project) should not use /usr/local:

1. /usr/local is in the default library and include search path. If you put something in /usr/local, you are damning anyone doing their own development on the system to linking against your stuff. GCC looks for things in /usr/local by default. If your project sticks something in /usr/local that it depends on, but never updates, people will find that down the road, something else has broken.
2. /usr/local is for the local system administrator. The only person who should be putting things in /usr/local is the person who runs the system. That way they know it's there, and if there are problems with it being in the default GCC path, they will know to fix them. 3rd-party projects traditionally belong in /opt. If I was part of the Fink project I'd have suggested putting it in /opt/fink instead of /sw as that is the proper place for 3rd-party packagers to put things. But I wasn't, and changing from /sw to /opt/fink now would break many systems, so I have no objections to leaving it as-is, the net result is the same.

The same general rules apply to working with frameworks. You should never put your framework in /System/Library/Frameworks, that's equivalent to writing stuff to /usr/lib -- it's reserved for Apple. If you make your own projects, put it in ~/Library/Frameworks, or, the equivalent to /usr/local for frameworks: /Library/Frameworks.

In this post, he refers to "GCC bugs" and problems with Virex that just don't make sense:

There are a number of things I think he could be referring to:

• The "GCC bug" he's referring to could be the fault of OpenOffice's (IMHO) horrible behavior of installing an old dlcompat into /usr/local that's incompatible with Panther. Panther now includes Pogma's dlcompat code in libSystem, and if you have old headers lying around it will cause problems. This is exactly why you should not ever install stuff in /usr/local as a 3rd-party packager.
• Another possible problem is if he's got a Fink that was built on 10.2 before we were Panther-aware; if he followed the upgrade instructions he would no longer have any stray dlcompat headers (if, in fact, that was the issue).
• Another possibility is he's referring to Fink's prebinding system. At one point, Fink's prebinding setup would add environment variables to force prebinding to everyone's shell if they use Fink. That was a bug (my bug, in fact), and has been fixed for months.
• The Virex problem is not Fink's problem, but Virex's. As mentioned earlier, instead of properly relocating the libraries they used from Fink into their bundle (using install_name_tool), they just unpacked software into /sw directly. There is no way I can even imagine of thinking this would be OK. /sw is a known directory for Fink stuff; if they knew enough to link against it, they should have known better than to overwrite it. This has since been fixed, and is, I believe, a non-issue.
• He could have even been referring to something else. We take compilation bugs (especially anything that breaks GCC, or working with software outside of Fink) very seriously. If I'd gotten an e-mail about broken GCC issues, I would have looked into it immediately. I don't recall any such message to our lists or bug reporter (granted, we get thousands of messages a month, perhaps I just missed it).

And this is the most obvious FUD, right here:

My earliest post about running Fink on Panther was early October. By late October things were generally working and shortly after that we had our first officially supported test release for 10.3. Support (and available packages) rapidly increased and we now have a binary distribution for 10.3-specific packages that fixes most of the issues encountered in the 0.6.x series on Mac OS X. Making the move to Panther was hard. Many things broke, and it meant splitting our time between 2 different systems, since this is the first time we've supported 2 different Mac OS X releases simultaneously. (When Jaguar came out, we immediately dropped 10.1 support.)

I've got no problems with legitimate concerns with Fink. We don't do everything perfectly. I do have problems with comments that can't be called anything other than FUD.