Here are some facts about Fink.
1) Fink does indeed put itself first in your PATH, inserting /sw/bin and
/sw/sbin there. Some people object to this; they might prefer DarwinPorts,
a similar system which puts itself last in your PATH.
2) Fink really discourages you from installing into /usr/local, precisely
to avoid having Fink "pollute" your non-Fink compiles. What's the connection?
Well, the default search path for headers and libraries used by most
compilers and linkers includes /usr/local/include and /usr/local/lib.
If Fink is installed into /usr/local, you can never avoid linking in Fink
stuff. (The same applies to software you get from any third-party source:
if it went into /usr/local, it will affect what you later do.)
3) However, if you install Fink anywhere other than /usr/local, it really
*won't* pollute your other compiles. You have to explicitly set flags like
-I/sw/include and -I/sw/lib to get Fink libraries involved with your
compiles. So it's pretty easy to have Fink installed, and yet avoid it
when you want to.
[Incidentally, points 2) and 3) together explain why Fink is so insistent
on installing things in a so-called non-standard location like /sw: the
point is precisely to avoid a DLL-hell type of situation, since Fink wants
to control everything that goes into its filespace.]
4) The point of Fink, and of DarwinPorts, is to provide the extensive library
of existing Unix software on the OS X platform, in a coherent and coordinated
distribution. If you don't want that, don't install these. If you think
that everybody should be using Frameworks instead, then start an open source
project of like-minded people and package things up using Frameworks. It
will be harder to do than Fink, since you will have to make more modifications
to existing software, but it may well be worth the effort.
5) The dlcompat software was developed by members of the Fink project,
building on some early work of Apple engineers, and has now (in 10.3) been
included back into Apple's libraries. This is a great example of how the
open source community can collaborate successfully with Apple.
6) To the best of my knowledge, it's impossible for Fink to cause a gcc bug.
Fink certainly makes use of some of Apple's recent gcc extensions when it
builds software, and it has begun to do things -- such as prebinding libraries
-- which don't work properly with every software package. The poster who
mentioned a gcc problem with Fink is invited to contact me directly to further
discuss whatever the problem was.
Fink has lots of problems, of course, some big and some small. This is to
be expected from any open source project involving more than forty volunteers,
almost none of whom are computer professionals.
Bottom line: if you don't like it, don't use it. If you love it, consider
helping out!
-- Dave Morrison
Co-leader of the Fink project
P.S. Everything is open in Fink. This means in particular that even if you
hate Fink, you'll be able to borrow the patches or compiling tricks from
the Fink team, and compile things for yourself without using Fink's
automated system, installing them wherever you like. Fink welcomes such
"partial users" as well as the users who want to install the entire system.
_______________________________________________
scitech mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/scitech
Do not post admin requests to the list. They will be ignored.
