Creating local packages

As explained in the local packages post, sometimes it might be necessary to create a local package in order to test or use different build options. For example, Fink’s libgpiv3 package doesn’t have the DEBUG macro enabled and therefore libgpiv3 doesn’t dump messages that are useful when there’s need for debugging. I’ll use this package as an example of how to create a local package.

Copying files to the local tree

The first step is to copy the package description and necessary patches to the folder finkinfo in the local tree, /sw/fink/dists/local/main/finkinfo. In order to find the name and location of the package description file (and patch file if it exists), run the command

fink dumpinfo -finfofile -fpatchfile libgpiv3

It should output something similar to

infofile: /sw/fink/dists/unstable/main/finkinfo/sci/libgpiv3.info

This shows that libgpiv3 has no patch file.

In order to copy the package description to the local tree, run

cd /sw/fink/dists/local/main/finkinfo
sudo cp /sw/fink/dists/unstable/main/finkinfo/sci/libgpiv3.info .

If you’re changing a package that has a patch file, don’t forget to copy it as well.

Editing the package description

Use your favourite text editor to open the local package description – you’ll need administrative rights to do that (e.g. sudo). The first step is to change the revision number so that the local package description appears to Fink as the most recent one. At the time of writing, the current revision number of libgpiv3 is 3, so change it to (say) 4:

Revision: 4

In order to define the DEBUG macro, add its definition to the SetCFLAGS field:

SetCFLAGS: -Os -DSYSTEM_RSC_DIR="\"%p/etc\"" -DDEBUG

Revision, SetCFLAGS and other fields are explained in the Packaging Manual, Fields section.

Save the file and check if it’s ok by running the command

fink -v validate libgpiv3.info

Building and installing the local package

Before building the local package, tell Fink to scan the trees so that it’ll detect the local package in the local tree:

fink index

If you run that previous fink dumpinfo command again you’ll see that Fink now considers the local package as the most recent (and the one it’ll use from now on).

Now build the package:

fink -m --build-as-nobody rebuild libgpiv3

Alternatively, you might want to save the build log (located under /tmp) in order to check if -DDEBUG is actually being used:

fink -lm --build-as-nobody rebuild liggpiv3

If the package builds fine then you should have two .deb files (libgpiv3, libgpiv3-shlibs) under /sw/fink/dists/local/main/binary-darwin-i386 (or whathever is the architecture of the system you’re building on). Now install the package via

fink install libgpiv3

Version updates

Fink always tries to use the most recent version/revision of a package. This means that if Fink’s original package is updated then yours won’t be used in subsequent selfupdates – if a local package has version/revision <= Fink’s version/revision, Fink will use its own instead. See the local packages post.

If the local package has a patch file and you want to update it to a newer version, make sure that the patch file is suitable for that version.

Submitting a package to Fink

If you think that your local package would be useful for other users, consider submitting it to Fink. If the package has a listed maintainer in its description file, contact the maintainer via e-mail. If the maintainer is listed as None, add yourself as the maintainer of your local package (and perhaps the original package too!) and submit it to the Submissions tracker on SourceForge.net. Depending on the changes it might warrant a new package name, e.g. libgpiv3-debug.

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!

Local packages

Fink comes with a given set of packages that are collectively referred to as a distribution. A distribution depends on whether the user has installed Fink using the binary installer or bootstrapped from source, on the selfupdate method (point, rsync, cvs), on the last time the user has selfupdated, and on whether the user has enabled the unstable tree.

There’s yet another option to change Fink’s distribution: local packages, installed under /sw/fink/dists/local/main. These are packages (either a .deb binary package, or a .info package description) that are not written by Fink itself but are used by Fink whenever appropriate. Normally users don’t need local packages, but there are some situations where they might be necessary:

• a new/updated package is on the Submissions tracker but has not been accepted by Fink yet;
• a new/updated package that the user has packaged and intends to submit to Fink;
• downgrading a Fink package;
• testing/using different build options.

A local package description (.info file, and .patch file if it exists) should be placed under /sw/fink/dists/local/main/finkinfo. Running

fink index

makes Fink recognise local packages and add them to the distribution. After that, you may use these local packages like any other package.

If a local package is also present in Fink’s distribution then there are a couple of things to consider:

• Fink always uses the latest version/revision of a package. This means that if you have a local package that at the moment is more recent than Fink’s then it’ll be used until Fink’s version/revision gets updated to a more recent version/revision.
• If a given package exists in different trees with same version/revision, then Fink uses the last tree, as defined in Trees in /sw/etc/fink.conf, that contains that package. In a default Fink installation, the order of Trees is local, stable, unstable.

Hence if you want to use a local package instead of Fink’s, make sure your version/revision is more recent than Fink’s. Remember that problems arising from local packages are essentially unsupported by Fink.