Fink:buildlocks

The buildlock subsystem

Buildlocks are designed to prevent concurrent fink processes from interfering with each other's dependencies. For example, if one fink process is compiling a package "foo" that has a build-time dependency on the package "bar-dev", that fink process will set a build-lock that prevents another fink (or dpkg or apt or...) from removing the bar-dev package until the first fink process finishes building the package foo. In addition, buildlocks prevent concurrent builds of any given package (name-version-revision) to prevent the build processes from over-writing each other's files.

Lock packages

The main component of a buildlock is an actual additional package that fink installs. Each buildlock package name is composed of the string "fink-buildlock-", followed by name, version, and revision of the packge whose build it represents, and the version string of the buildlock package is the date and time that the build was started. During the time that this package is installed, you will not be allowed to install, remove, or upgrade any packages if such an action build violate the dependencies of the build process.

When a fink package-building process ends, its dependencies are no longer needed and the lock-package that protects them can be removed. This package removal happens automatically when a package builds successfully, and usually when a package build fails as well. Unfortunately, there are times when a package build fails so badly that the lock-package may not get removed properly. This situation can also occur if something interferes with the lock removal process itself, for example the computer being turned off, or a user pressing control-C or other interrupt.

Install levels

There are two main steps in installing a package:

1) The package tarball is unpacked, patched, configured, and compiled into a debian archive. This part is done by the fink executable using a variety of helper programs.

2) The debian archive is then is used by the dpkg program to actually put useful parts of software where it can be ran.

The significance of this is because fink can complete its part and the failure occur during the dpkg part. In this case, the error message will mention dpkg specifically. When it does, there is nothing that the fink executable can do to fix the error, proceed directly to the last bulleted item.

Common causes of buildlock failures

• Trying to install or remove a package, if such an action would violate a build-lock's dependencies.

Wait until the build has completed.

• Trying to build a package when that package is already in the process of being built.

Wait until the build has completed.

• Trying one of the above actions when there are dead locks left from a previous, failed attempt to compile a package.

Remove the lock manually. fink list -t fink-buildlock will list them, then you can use fink remove package-name to remove them as with any other package. Eventually, fink cleanup will provide a cleaner interface for this housekeeping task. Eventually, fink will automatically clear dead buildlocks at various points in its processing. Note--the "eventuallys" have been implemented as of fink-0.26--Alexkhansen 14:54, 8 March 2007 (CET)

• Installing the buildlock package when fink is confused.

The dependency engine used by fink is not perfect. Sometimes if you request a build that entails many other builds or have a single fink command build many packages at once (for example, fink update-all), it will try to build a package with the wrong dependencies installed. The crash will tell you which package fink was trying to build at that moment: try to have fink build just that package, which will usually succeed, then you can retry the original command that led to the crash. Note that for complex build requests, you may have to go through several iterations of build-a-package/retry-the-whole-set...each time you will get further through the process. Packages whose builds had succeeded before the crash will not need to be rebuilt.

• Installing the buildlock package when dpkg is confused.

Symptom: An error message like the following:

dpkg: parse error, in file `/sw/var/lib/dpkg/status' near line 537
package `fink-buildlock-antlr-2.7.4-2':  missing version

This situation is an example of Fink FAQ #6.13. For buildlocks, there is a simpler solution that often works.

This error occurs if a build ends ungracefully, e.g. if the machine loses power in the middle of it. In such an event the buildlock package isn't toggled to "not-installed" in dpkg's status file, whereas fink doesn't think it exists. dpkg expects that any package that shows up as "installed" needs to have a version plus other information.

To fix this you'll need to edit /sw/var/lib/dpkg/status as root, go to the line number that is complaining, and change install ok installed to purge ok not-installed.