Tag Archives: configuration

Fink’s xinitrc, GNOME, and KDE

Fink’s xinitrc package provides similar functionality to X11 on 10.4 as is available on 10.5 and 10.6.   It provides Fink packages with a straightforward way to have executables run automatically when X11 is started without modifying the system area, instead using scripts in /sw/etc/xinitrc.d (assuming a default fink setup).  Moreover, when a package is removed, its script will also be removed.  Currently, the following packages use it:

  • dbus
  • kinput2
  • uim
  • user-ja
  • xfontpath

xinitrc is used by these packages on 10.5 and later as well as 10.4.  Since dbus is in the dependency chain for both GNOME and KDE, the behavior of xinitrc is important for users of those desktop environments.


xinitrc does have a side effect that needs to be taken into account.  It is set up, deliberately, to circumvent the default script setup from 10.5 or 10.6’s X11 with its own, similar, setup, cf.:
and its default setup doesn’t search $HOME.xinitrc.d for user scripts.
Fortunately, it’s straightforward to do so, and the method provides 10.4 users with the ability to set up scripts in $HOME/.xinitrc.d, too.

Also, if you’re using xinitrc because other Fink packages Depend on it, you may lose some functionality if you need to reinstall X11 (e.g. if you’re using Xquartz on 10.5).  If so, then use

fink reinstall xinitrc

to restore it.

10.5 and 10.6

Basically, we just need a way to reactivate the existing handling of $HOME/.xinitrc.d .   The xinitrc package provides a couple of system administrator entry points.  Let’s use  one which gets processed after the script files that are installed by fink packages.  We can do this via the following steps:

  1. Edit /sw/etc/xinitrc-last-hook as a superuser (again assuming a default Fink path).
  2. Put the following in it:
    . /usr/X11/lib/X11/xinit/xinitrc.d/98-user.sh

    and save the file.

  3. That’s it! The next time you start X11, it will process any scripts in $HOME/.xinitrc.d .


10.4 requires writing the script that processes scripts in $HOME/.xinitrc.d :

  1. Edit /sw/etc/xinitrc-last-hook as a superuser (again assuming a default Fink path).
  2. Put the following in it:
    if [ -d "${HOME}/.xinitrc.d" ] ; then
    for f in "${HOME}"/.xinitrc.d/*.sh ; do
    [ -x "$f" ] && . "$f"
    unset f

    and save the file.

  3. That’s it! The next time you start X11, it will process any scripts in $HOME/.xinitrc.d .

Setting up GNOME or KDE

To make sure that GNOME or KDE get started after any other apps, we will want to give their startup scripts names that get processed after anything else we want, e.g. ‘zzz-gnome.sh’.

Full GNOME Desktop

  1. Edit e.g. $HOME/.xinitrc.d/zzz-gnome-session.sh .
  2. Put the following in it (assuming a default Fink setup):
    . /sw/bin/init.sh
    metacity &
    exec gnome-session

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzz-gnome-session.sh

    to make the script executable.

Rootless GNOME

  1. Edit e.g. $HOME/.xinitrc.d/zzzz-gnome-panel.sh .
  2. Put the following in it (assuming a default Fink setup):
    . /sw/bin/init.sh
    metacity &
    exec gnome-panel

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzzz-gnome-panel.sh

    to make the script executable.


  1. Edit e.g. $HOME/.xinitrc.d/zzzzz-kde3.sh .
  2. Put the following in it (assuming a default Fink setup):
    . /sw/bin/init.sh
    exec startkde

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzzzz-kde3.sh

    to make the script executable.


  1. Edit e.g. $HOME/.xinitrc.d/zzzzzz-kde4.sh .
  2. Put the following in it (assuming a default Fink setup):
    . /sw/bin/init.sh
    exec /sw/opt/kde4/x11/bin/startkde

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzzzzz-kde4.sh

    to make the script executable.


User Customization of X11 on 10.5 and 10.6

The use of a $HOME/.xinitrc file to customize X11 has been deprecated as of OS 10.5.  Unfortunately, due to time constraints, we haven’t set down in the documentation what users should be doing.  I hope to set some ideas down here to clarify the situation.

The old way:

The presence of a $HOME/.xinitrc file replaces the system’s default X11 startup sequence.  A couple of consequences are:

  1. The user must make sure to run a window manager (unless one isn’t desired), e.g. just having
    will generate an xterm with no window decorations, and any further X11 applications started from that xterm will be unmanaged. In this case the user probably wanted something like
    xterm &
  2. The user must make sure that $HOME/.xinitrc ends with a non-backgrounding command, or X11 will quit immediately. This would be the case in the prior example above if the user had
    xterm &
    quartz-wm &

The new way:

Instead of a single $HOME/.xinitrc file, under the current incarnation of Apple’s X11 (and any Xorg 7, really), one can do the following:

  1. Create the directory $HOME/.xinitrc.d
  2. For anything you want to run, create an executable shell script in that directory.  For example, to run Fink’s xpad application on startup, create a $HOME/.xinitrc.d/xpad.sh (the name is somewhat arbitrary, but see below) with contents
  3. and make it executable via

    chmod a+x $HOME/.xinitrc.d/xpad.sh

    Note that in this case you don’t have to set a window manager.

    The window manager can be changed in the same way.  There is only one subtlety:  the contents of  $HOME/.xinitrc.d are run in the order that the filenames appear in a listing, and generally one will want the window manager to be run last, so its script should be named appropriately. For example, you could have 0-xpad.sh and 99-evilwm.sh scripts to run the evilwm window manager and start xpad automatically.

  4. It’s easy to keep a list of scripts that start one item, and to set whether they get run or not by using
    chmod a+x <name of script>.sh


    chmod a-x <name of script>.sh


Note: It’s slightly more complicated to set things up for GNOME or KDE, and I will discuss that issue in a subsequent entry.

SelfUpdateTrees and Distribution in fink.conf

There are two entries in /sw/etc/fink.conf whose values seem to refer to a Mac OS X version.

The Distribution entry must contain the OS X version of the machine, so if you installed Fink on Snow Leopard, it should be 10.6.

The SelfUpdateTrees entry is different. For Mac OS X versions prior to 10.5 Fink used to organise package descriptions according to the OS X version, so there used to be different trees: 10.2, 10.3, 10.4. Whenever a user ran

fink selfupdate

Fink would download the package descriptions of the tree corresponding to the specific OS X version where it was installed.

With the release of Mac OS X 10.5, Fink decided not to have different package description trees any longer and reuse the 10.4 tree instead. Therefore SelfUpdateTrees: 10.4 is the correct entry in fink.conf on Mac OS X 10.4, 10.5, and 10.6 because the 10.4 package description tree is shared amongst these OS X versions. This might change in the future.

Note that in general users shouldn’t change the Distribution and SelfUpdateTrees entries. These are created when Fink is installed and updated, if necessary, when Fink is updated.

Starting anew

Some users have been asking how to reinstall Fink. This might be necessary when there isn’t an upgrade path — for instance, there’s no upgrade path from 32-bit Fink to 64-bit Fink, or when trying to replicate a Fink installation from one architecture (e.g. PowerPC, 32-bit Intel) to another (e.g. 64-bit Intel). This text explains how to save the list of installed packages and their configuration files in order to conveniently reinstall them on a clean Fink installation. Bear in mind that packages in one platform may not be available on another. For example, some packages are only available for PowerPC, and 64-bit Fink has (at the moment) fewer packages than on 32-bit Intel, 32-bit Fink.

Note: if you’re not sure how to execute the commands listed below on a terminal window, contact someone that’s more familiar with Unix and shells.

Preamble: Understanding virtual packages

Virtual packages are placeholders for packages or features that are present on your system but haven’t necessarily been installed by Fink itself. Some of them are system virtual packages, representing files that are shipped with the system (e.g. system-java, system-perl), whilst others may represent files installed by either Fink (e.g. pdftex) or the user (e.g. growl). Some of these virtual packages do not actually refer to files on your system. For example, the 64bit-cpu virtual package is just an indication that the system has a 64-bit processor. At any rate, virtual packages are managed by Fink and you can’t run commands fink install or fink remove on them.

Listing installed packages

Fink provides a handy command to list installed packages:

fink list --installed


fink list -i

for short. This command outputs a human-readable list of packages that are considered to be installed on your system, including packages you’ve installed yourself, their dependencies, and virtual packages. The following command trims virtual packages off this list:

fink list -i | grep -v " p " | grep -v "\["

We may use the -t flag and the cut command to get a nice list of installed packages that doesn’t include virtual packages:

fink list -it | grep -v " p " | grep -v "\[" \
| cut -f2

In order to save this list to a file (e.g. instpkgs.txt) for further reference, use the command

fink list -it | grep -v " p " | grep -v "\[" \
| cut -f2 > instpkgs.txt

Saving configuration files

If you’re planning on removing your entire /sw folder then you should consider saving your configuration files. Fink’s configuration file is /sw/etc/fink.conf. Packages may also place configuration files under /sw, usually under but not limited to /sw/etc (on my system there are package configuration files under /sw/etc, sw/lib, and /sw/var).

The following command lists the configuration files of every package in instpkgs.txt as created in the previous section, saving the list in conffiles.txt:

cat instpkgs.txt | xargs fink dumpinfo -fconffiles \
| sed "s/^conffiles: //;s/^[ \t]*//" | tr " " "\n" \
| sort | uniq > conffiles.txt

Browse through this list and backup the configuration files you want to keep (don’t forget to write their original location down). Some of them don’t need to be backed up (e.g. /sw/etc/passwd-fink). If you want to know which package installed a certain configuration file (e.g. /sw/etc/pkgconffile.conf), run the following command:

dpkg -S /sw/etc/pkgconffile.conf

Please note that if you’re changing from a 32-bit Fink installation to a 64-bit Fink installation then it is possible that old configuration files won’t work on the new installation. As this is particular to each package there’s no general solution for it. If you’re changing from one OS X version to another, or from 32-bit Fink to 64-bit Fink, it is also possible that your old fink.conf won’t work on the new installation, especially the Distribution and SelfUpdateTrees entries. You’re better off using your old fink.conf as a guide when answering the questions asked by Fink during installation/bootstrapping or when running the

fink configure


Local packages

If you’ve created local packages under /sw/fink/dists/local, don’t forget to backup them up. You probably won’t need to keep the binaries so it should be safe to keep only the package descriptions and patches; those are usually under /sw/fink/dists/local/main/finkinfo.

Removing Fink

Every file installed by Fink is under the /sw folder, so running the following command will wipe out your Fink installation:

sudo rm -rf /sw

Well, not exactly. Fink also places convenient shortcuts under /Applications/Fink for packages that are application bundles (those special folders whose name end with .app). If you use the fink remove command to remove a package that provides an application bundle then the equivalent shortcut is removed. However, if you simply remove the /sw folder, the shortcuts won’t get removed, so you might want to do that yourself.

Depending on how you’ve installed Fink or if you’ve run the pathsetup shell script, you might have a line resembling

test -r /sw/bin/init.sh && . /sw/bin/init.sh

in your $HOME/.profile shell initialisation script (or the equivalent command/file for csh, tcsh). The line above can be left there if you’re planning on reinstalling Fink. It is also harmless to leave if there if Fink is not installed.

Installing Fink

Follow the installation instructions on Fink’s Web site. Recall that at the moment there is no binary installer for OS X 10.6, Snow Leopard, so you need to use the source installation from version 0.29.9 or higher.

Reinstalling the packages

You may use the instpkgs.txt created in the Listing installed packages section. The following shell script reads that file, line by line, and runs Fink’s installation command on each package:

cat instpkgs.txt | while read pkg
  fink install $pkg

Note that if you’re using sudo then this shell script will ask your password every now and then. You might want to save the whole script to a file (e.g. reinstall.sh) and run it with sudo (e.g. sudo ./reinstall.sh).

As some of the packages in instpkgs.txt are dependencies of other packages it is quite probable that you’ll get some No packages to install warnings which may safely be ignored — they mean that the command above is trying to install a package that’s already been installed. If a package is not available on your new installation, you’ll get Failed: no package found for specification errors.

You may also want to restore the configuration files you’ve saved. Remember that if you’ve changed from one platform to another there might be differences in the configuration files. Whenever possible, use the application itself to enter the configuration, using the old (backed up) configuration file as a guide.

If you’ve backed up your local packages, restore them to /sw/fink/dists/local and run

fink index

so that Fink becomes (once again) aware of them.

Packages and configuration files

Some packages have configuration files that can be edited by users. Usually these configuration files are located under /sw/etc; some common file extensions are .cfg, .conf., and .ini.

Fink has two different behaviours when removing a package that has installed configuration files. If the user runs

fink remove package

then Fink (internally, its dpkg implementation for .deb management) doesn’t remove any configuration files installed by the package. This is handy because subsequent installs/updates of that package will keep previous configuration. On the other hand, it is possible that newer versions of the package have different entries in the configuration files. In general, it is up to the application to manage these differences.

What if a user wants to remove a package and its configuration files? The command

fink purge package

will do that.

In order to check if a given package has configuration files that are preserved when the package is removed, run the following command:

fink dumpinfo package | grep -i conffiles

If you want to check which package has installed a configuration file (e.g. /sw/etc/package.conf), run the following command:

dpkg -S /sw/etc/package.conf

If you are a packager, specify the configuration files in the field ConfFiles in your package description.