To Fink or not to Fink

[Ellen]

I would like to know the pros and cons of using Fink.

I have currently installed PostFix, ProFTPD, XFree86. PostFix I compiled from source (very easy), For ProFTPD and XFree86 I used precompiled versions. Installation went smoothly.

Now I am looking into installing some other stuff and, having read many forum messages here and elsewhere, I find some people are very pro-Fink and others aren't. Now, my point is not to know if Fink works or not (I know it does) but only to figure out if, for me, it is a good choice or not. My impression is that it may be very useful for some things and not so useful for others but I don't know for sure what is what.

So can you tell me why you use Fink or why you don't, and what you use it or don't use it for?

Thanks.

Ellen

[rv8]

I like several things that Fink offers:

1. Installing something with Fink does not overwrite components that were installed as part of OS X. For example, if I install a newer version of ssh with Fink, it goes inside Fink's own sw directory. Then, if I decide that I don't like this new ssh for some reason, I can remove it, and the Apple version is still intact. Beware package managers that install in the normal unix directories, as they will overwrite Apple's software. You need to be 100% sure the new stuff will be good before you overwrite the Apple stuff.

2. There are two very active and helpful e-mail lists. The few questions I have had have been answered very quickly. See http://fink.sourceforge.net/lists/index.php

3. Many Fink packages seem to get updated fairly quickly to follow updates in the basic unix source. Note: you need to setup Fink to use the unstable software tree if you want to get these updates. They eventually get over to the stable tree, but there can be a long delay. Using the unstable tree does sound a bit scary, but in truth I have had no more trouble with the stuff in the unstable tree than the stable one. I do make a practice of waiting a day or two after any update comes out before installing it, to let other users catch any major bugs.

Like any software collection, sometimes what you want hasn't been ported to Fink yet. There is a page to request new packages, and the one request I have made was answered with a new package in less than a week.

I used Fink to install xFree86, Windowmaker, Sawfish, xEphem, Grace, Spice, Oregano, Abiword, Gnumeric, Mozilla, Dillo, Bluefish, Amaya, and many, many other packages. I haven't tried other package managers, so I guess I'm not sure what I'm missing, but I am very, very happy with Fink.

Note: probably less than 25% of the packages are available as part of the binary distribution. You'll probably want to get the developer tools, and be prepared to compile stuff. Fink automates the compilation process, but some of the larger packages do take many hours to compile.

[osxpez]

Fink is awesome. It saves tons of time to be able to do:

$ apt-get install screen

rather than finding the source, figure out how to configure it and then compile. I'd say that most stuff you really want are available as apt-get installable binaries. Most of the rest are available for fink-compile-install.

Should you find the need to download something and install it the old way you just do it. Fink doesn't really care.

For once you can both eat the cake and keep it. =)

[porkchop_d_clown]

Fink is great for offering true uninstall (which few *NIX programs do when compiling from source).

The only problem I have with fink is the way it creates a great glob of user ids for packages you may not have installed.

One other warning - if you've built and installed things by hand, and there are fink packages for those things, you can have problems - mostly because fink isolates all it's packages in a special directory, but things you've installed by hand are probably in /usr/local.

[mervTormel]

ellen, i suggest you install fink and a few small test packages, something out of the util tree like findutils, fileutils, grep, less, etc., and give it a whirl to see how it works. those will give you a good idea how fink's /sw path works to supercede the vanilla OSX PATH string.

but, here's a trick for command juggling...

you can easily promote /usr/local/ commands with symlinks in, for example, your personal bin dir...

consider the default fink install:

PATH="/sw/bin:/sw/sbin:/Users/merv/bin:/usr/local/bin:/usr/bin:/bin ..."

versus promoting your personal bin dir:

PATH="/Users/merv/bin:/sw/bin:/sw/sbin:/usr/local/bin:/usr/bin:/bin ..."

and symlink to a /usr/local/ command

% ln -s /usr/local/bin/bash ~/bin/bash

hence, local installed bash will override fink's bash. then, all you have to manage is the contents/symlinks of your personal dust bin to juggle which command is caught.

i have a bash script called 'wiz', that provides deeper coverage for which/whereis. it searches all PATH elements and reports found commands. i find it useful in seeing commands that are superceded by my personal bin, and fink's tree over the vanilla PATH elements.

i shall post it here, after i clean it up a bit.

[macubergeek]

fink is awesome....simply because it offers the easiest and most painless install of xwindows on macos x, ROOTLESS and with a windows manager!!!!
I use it primarily for this reason. Only con I can see is it supports only about 400 or so packages, but I see that increasing with time.

fink is so good I put it on my corn flakes in the morning. merv, I'd love to see that script when it's finished

[mervTormel]

finished? perpetually 98% finished. in bash, using 'which' is wonky because it runs as a csh shell script. and whereis only looks in sysctl's user.cs_path

$ sysctl -a | grep path
user.cs_path = /usr/bin:/bin:/usr/sbin:/sbin

so, use wiz and get more information, more efficiently... <marketing off>

$ cat wiz

#!/bin/sh

#  wiz - whereis but find all pathnames of command(s) in your $PATH
#  Usage: wiz command [commands...]

testx="/bin/test -x"
echo="/bin/echo"
sed="/usr/bin/sed"
bash="/usr/local/bin/bash"

# replace null field in $path with a .

fixpath="`$echo $PATH | $sed \
  -e 's/^:/.:/' \
  -e 's/::/:.:/g' \
  -e 's/:$/:./'`"

IFS=":  "       # set $IFS (colon, space, tab) for parsing $PATH

for command
do
  where=""

  # if directory has the command, add it to list

  for dir in $fixpath $PWD
    do $testx $dir/$command && where="$where $dir/$command"
    done

  case "$where" in
    ?*)  $echo $where   ;;
    "")  $bash -c "type $command" 2>/dev/null
  esac
done

return $?

#  wiz looks in each directory in your $PATH (command search path)
#  for executable file(s) whose name(s) you specify.  if it finds the
#  file, it returns the file's full pathname.  if it doesn't find the
#  command(s), wiz returns nothing.

#  added bash command type; blab about builtins

i found this somewhere, can't remember where. it's public domain.

[sao]

Ellen,

Fink is free, fast and reliable. You can't go wrong with it, and you will learn things. Has support 24/7 through the mailing lists.

(But it's not for dumb brains)

If you feel you don't need it anymore, it's extremely easy to uninstall, as it keeps all the things at one place. (/sw)

Give it a try and start installing at your heart's content.

Good luck.


Cheers...


PS: MervTormel, thanks for the script . Good work.

[Ellen]

Thanks all for the good words.

porkchop_d_clown(what a handle :-)) says:

Quote: The only problem I have with fink is the way it creates a great glob of user ids for packages you may not have installed.

Hmmm. I'm a bit obsessive about my system and really don't like this idea. Can I know which ones are used and which ones are not? Can I delete the ids that aren't?

Quote: One other warning - if you've built and installed things by hand, and there are fink packages for those things, you can have problems - mostly because fink isolates all it's packages in a special directory, but things you've installed by hand are probably in /usr/local.

I know about this sw/ directory. It is, in my opinion, a good idea. But I don't see why it would cause problems with things that I installed by hand. Can you explain a bit more?
Unless you mean it can cause problems if I install something with Fink that I've already installed by hand. But I really wouldn't do that.

mervTormel:
Yes, I get the idea (of your trick for command juggling). But I suppose most of the time you won't have the same program twice.
Unless, as mentionned above, I want to install a program with Fink that I've already installed by hand. But then I figure I would start by removing the first one.

macubergeek:
I installed the precompiled version of xfree86 from the XonX project at sourceforge and I don't see how it can get easier. Just double click on an installer and that's it. Even easier than many installs on OS 9 a few years ago. And PostFix was a breeze too (compiled from source). Not to mention fileutils that I got from www.gnu.org and compiled from source in a few minutes.
I feel Fink would really be useful for programs that need tweaking to compile on OS X, or for those that are so huge that compiling and installing takes hours.

sao:

Quote: and you will learn things.

Now there's a good point. But will I learn more with or without Fink?

Ellen

[porkchop_d_clown]

User Ids
If you install anything that needs it's own user id (MySQL, for example) Fink will also install a set of user ids that contains *all* the user ids for *all* such packages - currently around seven.

These user ids cannot be used to log in - but they allow Fink to correctly set security and permissions for files and processes related to a package. Downside - if you already had a user called "jabber", for example, his login just got trashed.

/sw conflicting with old packages

Okay - so, say you compiled and installed MySQL and put it in it's default location (/usr/local). Later, a new version of MySQL comes out on Fink and you decide to use that version instead: Problem - now you have two copies of MySQL installed, in different places. (I did this to myself.)

So - you don't install that package with Fink. Except you want to install a Fink package called "CoolReportTool" that uses MySQL. Problem: Fink doesn't recognize that you've already got MySQL installed and won't let you install CoolReportTool.

Sigh.

[porkchop_d_clown]

Ummm... I guess I should point out that I *do* recommend using fink. Just that if you do use it, don't mix and match - always use the fink versions of packages.

[Ellen]

porkchop_d_clown
I see. I suppose I can live with a few unused ids.

About the potential conflicts: isn't there a way (with a symlink maybe) to get Fink to see that MySQL is already installed?

Or couldn't you install "CoolReportTool" by hand?

Somehow I feel that Fink is some sort of addiction :-) Once you've started, you're hooked. And to get out isn't that easy.

sao:

Quote: If you feel you don't need it anymore, it's extremely easy to uninstall, as it keeps all the things at one place. (/sw)

But what do you do with all the stuff you've installed with it? You have to leave it where it is I suppose, or remove it altogether and reinstall what you want by hand. Can you move the stuff out of sw/ and into their normal places (assuming you know where that is...) or would you be better off reinstalling?

Ellen

[mervTormel]

i think one would be remiss by installing a fink package and then removing the vanilla one, or even the /local one.

somehow, this thread has hyper-mentalated into how difficult fink is once it has gotten legs in your rig. not at all true.

understand how the PATH variable works. install fink and some packages and the 'wiz' command above and investigate.

here's a contrived example:

let's say i installed fink's find, used it, wrote some find scripts. well, if those find scripts use fink find features, then references to find had better be the full path; /sw/bin/find

if i want command line find to be the vanilla find, i would make sure my personal /bin was before /sw in my PATH, and make a symlink in ~/bin to
/usr/bin/find

a couple of rules of thumb:

in scripts, always use full path to the command

never remove a command that may have this dependency

this makes your rig co-dependent. this may seem like a bad thing, but it's not. once you've written one line of code that is dependent on a command, it's no big deal to leave that config indelible. just learn the tricks that get the command you want when you want it.

[sao]

Ellen,

I can see that you know more that what you seem to tell us.

If you already installed Xfree86 with the installer from the XonX project (I did the same), then you already know what to do.

The rest you will learn as you go along. Unless you have some other goals.

To learn 'more' or to learn 'less' is not the question. It really depends on what you want and what you mean by more (more of what?). I repeat, you seem to know more that what you tell us.

Now to clear the field a little bit:

<<If you install a package which has a dependency on the 'passwd' package, then you will be installing 'passwd' which is a sort of general purpose package that sets up a couple of extra users on your system in the event that you someday decide to install packages that require these extra users.>>

The installer at some point do ask if you agree to the creation of this new users and only install them if you answer yes.

<<This installation is actually a security "feature". All unix processes have to run as one user or another. System processes generally run as the user root, but for a process such as MySQL to run as root would be a big security breach, so it creates a user with no privledges to run under. This user also becomes the owner of any files that the process needs to have write access to, adding another layer of security.
In theory you could have a single generic user account that all of these processes run under (some Linux systems use 'nobody') but this could get messy so it customary to have different accounts such as mail, news, apache, mysql, etc.>>

Please read this thread:

http://forums.macosxhints.com/showth...fink+new+users


Almost all files installed by Fink are in /sw (or wherever you chose to install it). Thus in order to get rid of Fink, you enter this command:

sudo rm -rf /sw

And all your installation will be gone. Then you can reinstall, by hand or using fink again, if you wish.

The only exception to this rule is XFree86. If you also need to remove XFree86, additionally enter this:

sudo rm -rf /usr/X11R6 /etc/X11 /Applications/XDarwin.app

This will delete your XFree86 installation as well as the XDarwin application.

And Ellen, the whole Apple enjoyment thing is an addiction too, this is the problem when things are that good.

I guess if you have the brain to ask so many questions in advance (unlike most people), you will surely do well, with or without fink.

Good luck. (and whatever you do please, let us know if it's 'more' or 'less', it's really interesting to read.)


Cheers...

[Ellen]

mervTormel and sao

Thanks for the support. Ok, I am quite convinced Fink is a good thing. I've got nothing against addictions that don't send you to the hospital :-)

And, Sao, I don't know what you mean by "I can see that you know more that what you seem to tell us.". So I'll tell you a bit more. I've been using a Mac since 1985 and have fiddled with unix a couple of times, either by obligation or for fun since 1994, but have never really delved into it for lack of time and motivation. Now, thanks to Mac OS X, I have the motivation, even if the available time hasn't expanded accordingly. On Mac OS BX (Before X) I have always wanted to know exactly what I was doing and have read all the manuals (yes, I really did...). So my approach to Darwin is the same. I need to understand. It may be a control thing (ask my shrink :-)). For instance, I absolutely hate installers that do things behind your back, and programs that think they know what's good for you (like 'smart' quotes...).

For now, I'll do some experimenting (with Fink too, yes) when time permits. I have set up a test machine with OS X Server for this. My real production server is up and running with the Apple modified and installed wu-ftpd and apache and nothing much else except Postfix (because of the open relay in the mail server before they fixed it recently). I've added BrickHouse and various little things but not much. I have another server with OS 9.x because I use a Panorama database. The plans are to migrate to MySQL or PostgreSQL and php or something similar. And for that, I need to understand all this thoroughly. So count on seeing me around.

Ellen

[sao]

Ellen,

Welcome, and I look forward to seeing you around.

You see, now you told me more of what you know (I'm a kind of shrink too).

I'm confident that you will manage very well.


Cheers...