Tag Archives: distribution

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.

Advertisements

Adopting a package

Out of 5,168 package descriptions, 550 (11%) are currently unmaintained. Adopting an unmaintained package is a good way to start working on Fink: you don’t need to start from scratch and you help keeping packages up-to-date.

The following command lists all unmaintained packages:

fink list --maintainer=None

Alternatively, you may visit this query at Fink’s Package Database.

If you feel like adopting an unmaintained package, the first step is to copy the package description (and patch if one exists) to your local tree, /sw/fink/dists/local/main/finkinfo. Package descriptions and patches are located under /sw/fink/dists. If you run

fink dumpinfo -finfofile packagename

then Fink will show you the location of the .info file that defines that package. Another possibility is to look for file names that resemble the package name, such as

find -L /sw/fink/dists -name \*tetex\*.info

Check if there’s a package.patch file under the same directory as package.info; if it exists, copy it to your local tree too. Apply the appropriate modifications (e.g. fields maintainer, version, revision) and build it in maintainer mode:

fink -m --build-as-nobody rebuild package

After having built a valid package, submit it (package description and patch) to Fink’s Package Submissions tracker at SourceForge.net (you’ll need a SourceForge.net account for that). The tracker is periodically checked and Fink committers review and apply submitted packages to Fink’s distribution. Please subscribe to the fink-devel mailing list as it is the official channel used by the Fink Core Group to send announcements to maintainers.

The authoritative packaging document is the Packaging Manual. There’s also a Packaging Tutorial available. If you need help with packaging, send an e-mail to the fink-devel mailing list or drop by the #fink IRC channel on irc.freenode.net.

Happy Finking!

Selfupdate methods: point, rsync, cvs

In Fink parlance, a distribution is a set of available packages which depends, amongst other things, on the trees defined in /sw/etc/fink.conf (local, stable, unstable) and the selfupdate method (point, rsync, cvs).

Fink defaults to the point selfupdate method in a brand new installation. The point distribution is the set of packages available when Fink last released a binary distribution. As these releases are not frequent, having a point distribution usually implies having outdated packages.

There are two alternative selfupdate methods that provide the latest packages: rsync and cvs. In the former method, fink selfupdate uses the rsync command to download packages descriptions from one of the rsync mirrors; in the latter, cvs is used to download package descriptions from SourceForge.net.

Choosing a selfupdate method

You should consider the following when choosing a selfupdate method:

  • whenever possible, use either rsync or cvs. They’ll get you up-to-date packages;
  • up-to-date packages are probably not available as official binaries. You’ll need to install Xcode to compile packages from source. You might want to check some unofficial binary distributions;
  • rsync is faster than cvs;
  • when a maintainer releases a new package it is readily available in the cvs distribution. In normal operation, new packages should reach the rsync mirrors in one hour at the latest;
  • firewalls might block rsync or cvs.

Note that when you switch from point to rsync/cvs your next selfupdate will take a while. Subsequent selfupdates should be significantly faster.

In order to switch to rsync, run

fink selfupdate-rsync

Or, if you want to use cvs, run

fink selfupdate-cvs

You can’t go back to the point distribution once you’ve switched to rsync/cvs.

After having changed the selfupdate method, run

fink update-all

to update your packages to their latest versions.

You only need to run selfupdate-rsync or selfupdate-cvs once. Fink remembers your choice and is going to use it in subsequent selfupdates.

Some Fink versions have a minor glitch that shows up when changing the selfupdate method. Please read this FAQ section.

Identifying which selfupdate method Fink is using

There are two ways to check what selfupdate method is being used in your Fink installation. If you run

fink –version | grep Distribution

and it shows something like

Distribution version: 0.9.0.2 architecture (e.g. i386)

then Fink is using the point distribution. If either rsync or cvs is being used, then the command above outputs

Distribution version: selfupdate-cvs (or -rsync), timestamp of last update, OS X version, architecture.

The other possibility is to check the SelfUpdateMethod entry in /sw/etc/fink.conf.

Distribution version: 0.9.0.2 i386

Fink and binary distributions

Fink was originally intended to be a package manager that automates the download-patch-build-install-update-remove process of software packages on Mac OS/Darwin. It also provides the necessary tools (based on dpkg and APT) to use binary distributions (bindists for short) of packages in .deb format, thus relieving users from the time-consuming build stage. Fink will use bindists if the following line

UseBinaryDist: true

is present in its configuration file, /sw/etc/fink.conf. There is also a command-line option, -b or –use-binary-dist, that instructs fink to use bindists in that particular execution.

Fink defaults to using its own bindist, which is mirrored throughout some servers around the world — the list of mirrors is stored in /sw/lib/fink/mirror/apt. Fink’s binary distribution contains binary .deb packages for softwares in the stable tree only. Furthermore, some licences restrict the distribution of binaries, thus not every package in stable has a respective .deb file available in Fink’s bindist. Creating an official, tested, and reliable binary distribution takes time, and the Fink Core team does not update their binary distribution that often.

Because of these shortcomings, and as Fink’s APT engine allows for using any number of bindists, some people have decided to provide unofficial binary distributions. Bear in mind that unofficial binary distributions are not supported by the Fink project. If you encounter problems with unofficial binary packages, please rebuild them from source before contacting the Fink project. Also bear in mind that the Fink project cannot vouch for the security of unofficial binaries.

The largest bindist is maintained by the Todai Fink team at the University of Tokyo, Japan. They have an automated build system that continuously builds binary packages using the unstable tree, targeting OS X 10.4 and OS X 10.5 on both Intel i386 and PowerPC, as well as OS X 10.3, which is no longer supported by Fink.

Another unofficial binary distribution is maintained by William G. Scott. As opposed to the Todai Fink team, William Scott has a few selected binary packages usually related to scientific computing, targeting OS 10.5 on Intel i386 and PowerPC, as well as OS 10.6. One notable difference between Todai’s and Scott’s bindists is that Scott provides GCC versions 4.3 and 4.4 — these are lengthy builds.

How does one add binary distributions to Fink’s APT engine? The file /sw/etc/apt/sources.list contains the list of APT sources/repositories. It is automatically managed by Fink for its basic operation, including the official binary distribution. You may modify it in order to add different (unofficial) binary distributions by inserting the following lines at the beginning or at the end of that file.

For OS X 10.6 on Intel, 64-bit Fink,

deb http://sage.ucsc.edu/fink_intel_10.6_64bit stable main crypto
deb http://sage.ucsc.edu/fink_intel_10.6_64bit unstable main crypto

For OS X 10.6 on Intel, 32-bit Fink,

deb http://sage.ucsc.edu/fink_intel_10.6_32bit stable main crypto
deb http://sage.ucsc.edu/fink_intel_10.6_32bit unstable main crypto

For OS X 10.5 on Intel, 32-bit Fink,

deb http://fink.sodan.ecc.u-tokyo.ac.jp/apt/10.5 unstable main crypto
deb http://sage.ucsc.edu/fink_intel_10.5_only    stable main crypto
deb http://sage.ucsc.edu/fink_intel_10.5_only    unstable main crypto

For OS X 10.5 on PowerPC,

deb http://fink.sodan.ecc.u-tokyo.ac.jp/apt/10.5 unstable main crypto
deb http://sage.ucsc.edu/fink_ppc    stable main crypto
deb http://sage.ucsc.edu/fink_ppc    unstable main crypto

For OS X 10.4 on both Intel and PowerPC,

deb http://fink.sodan.ecc.u-tokyo.ac.jp/apt/10.4 unstable main crypto

Recall that Scott doesn’t provide binary packages for OS X 10.4, so Todai is your only option.

After having edited /sw/etc/apt/sources.list, you need to run the command

fink scanpackages

on the command line in a terminal window, or the equivalent menu option in Fink Commander. This tells Fink’s APT engine to parse /sw/etc/apt/sources.list and read the packages provided by the repositories listed in that file. After that, you’re done! Next time you install a Fink package, Fink is going to use prebuilt .deb binary packages in these unofficial distributions if they are available.

A word of advice: these unofficial bindists are great but they’re unofficial. I recently ran into a problem with KDE when I used one unofficial KDE binary package and built another KDE package locally. Rebuilding everything locally solved the issue. You’ve been warned! 🙂