Misconceptions about 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:

Be aware that if you link against Fink libraries, you are not writing code for
MacOS X. You are writing code for Fink. The resulting code will not run on a
vanilla MacOS X system, which in my humble view is a 'really bad idea' (TM).

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:

[ x] Other, Fink has caused problems for program writers (like gcc), I can point to at least one GCC bug which is caused by how fink sets some environment variable while building and also how dlcompat was installed but now longer need for 10.3.


[X ] Other, I do not use Fink because of the problems I see it cause with other people and developers such as virex and really with GCC which is where I always see the most problems (but then again I am GCC developer and I believe in installing by source and by hand).

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 only problem with fink is that it has not been updated for Panther. It had been a no-brainer for years and then suddenly I was back in the old UNIX land of mysterious command line errors. I found after poking that lot's of stuff required hand patching (pdl, perl-pgplot etc) because fink had a hardwired '5.8.0' search path and Panther ended up at 5.8.1. I suspect a lot of the fink developers had a different version on the Panther beta. This was in Nov/December so maybe it has been fixed. I guess Apple should not have changed it, but then why does fink need to hard code stuff like this?

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.

Share on Facebook

6 comments to Misconceptions about Fink

  • Very well said, and far too politely I think. I have little respect for people who do not have the time to do a few seconds research, who just decide to spout off trying to sound as tho they know all about a subject. FUD sucks as to people who spread it intentionally.

  • The funny thing about this fud is that you can simply be a casual observer and know that some of the points are wrong or severely outdated. I’m not on fink’s mailing lists and I only update my install every so often. I probably visit the fink website every 2-3 months (now it doesn’t hurt that I know the Racoon, but he doesn’t describe every issue to me). I could recognize several of these as fud and the others I would probably ask about rather than going off half-cocked as such. You definitely needed to nip this one in the bud…
    nip it…nip it…nip it 🙂

  • Tony Arnold

    I agree with your comments about /opt/fink – I really think this should happen before fink hits 1.0 (which is a ways off *grin*). Then again, this would also make darwinports think about putting everything in /opt/dports, rather than /opt/local (which again seems to be quite silly)…
    Ack, it’s all a pain. I might try it and see how much breaks 🙂

  • Fink is perfectly capable of using /opt/fink right now, it’s just that the default for new installs (and the bindist) is /sw. Fink itself was written prefix-agnostic at source-build time.
    If you grab the fink source tarball and bootstrap manually, you can put it wherever you want. The same is true of darwinports, actually.

  • There are however some serious issues with using the fink version of g77 compiler, at least in some situations.
    The situation I am most familiar with is that AIPS (Astronomical Image Processing System), a fairly large package, breaks during install with readline dependency issues if you use the g77 from fink. I worked with the folks at the NRAO trying to get this fixed. The problem seemed to be with fink’s g77 and/or its readline library (both of which the Mac version of AIPS used to require!). The fink versions just could not be messaged into working. I tried emailing the maintainer of both fink’s g77 and readline packages about this and got no response. So our work around became to install g77 using the default install scripts into /usr/local/gnu, then a readline library in /usr/local/gnu, then install AIPS.
    I don’t fault the fink folks, its a hell of a job to stay on top of everything and I LOVE fink, it makes my life much easier. But it is not always going to be the perfect solution. In our case, it was fink’s g77 which when updated last summer became unusable for compiling AIPS. It is not bad programming on the part of folks at NRAO (who wrote AIPS) if a clean install of GNU g77 does compile AIPS.
    I suspect (but have no evidence supporting the idea) that the g77 in fink is carrying over some baggage from when the GNU g77 code had to be patched by fink to support darwin. Now that GNU g77 supports darwin right out of the tarball, whatever patching gets done by fink might be mucking things up.
    Just my two cents…
    Juan (A satistified fink user for over two years)