Fink

Packaging - 2. Package Descriptions

2.1 Tree Layout

Package descriptions are read from the finkinfo directories below the /opt/sw/fink/dists directory. The "Trees" setting in /opt/sw/etc/fink.conf controls which directories are read. The name of package description files must be the full package name plus the extension ".info". As of fink 0.26.0, there are several different ways to specify the filename: it is recommended to use the shortest version which is consistent with other needed package files. The filename takes the form: the invariant packagename, optionally followed by the architecture, optionally followed by the distribution, optionally followed by either version or version-revision, each delimited by hyphens, concluding with ".info". The "architecture" and "distribution" components are only allowed if the corresponding field is present in the package, and if it specifies exactly one value.

The package description tree is organized with several levels of directories. The directories in top-down order:

2.2 File Format

The description files are simple lists of key-value pairs, also called 'fields'. Each line starts with a key, terminated by a colon (:) and followed by the value, like this: 

Key: Value

There are two notations for fields that must span multiple lines.

The preferred notation is based on the here-document syntax in shell scripts. In this syntax, the first line consists of the key, followed by << as the value. All following lines are treated as the actual value, until a line with just << on it is encountered. The example from above now looks like this: 

InstallScript: <<
mkdir -p %i/share/man
make install prefix=%i mandir=%i/share/man
mkdir -p %i/share/doc/%n
install -m 644 COPYING %i/share/doc/%n
<<

Indentation using this format is optional, but it can be used to improve readability.

The here-document syntax can be nested. This is often used in a SplitOff or SplitOffN field. These fields contain other fields (multiple lines), and this syntax allows these sub-fields to have multiple lines themselves. The same terminator << is used for the sub-here-document. Here is an example: 

SplitOff: <<
  Package: %N-shlibs
  InstallScript: <<
    ln -s %p/lib/libfoo.2.dylib %i/lib/libfoo.%v.dylib
  <<
<<

In this format, empty lines and lines starting with a hash (#) are ignored. Keys (field names) are case-insensitive in Fink, so you can write InstallScript, installscript or INSTALLSCRIPT as you please. The first capitalization form is preferred for readability, though. Some fields take a boolean value - any of "true", "yes", "on", "1" (case-insensitive) are treated as true, all other values are treated as false.

2.3 Percent Expansion

To make life easier, Fink supports a set of expansions that are performed on some fields. In order to prevent ambiguity, you can use curly-braces to denote exactly what character(s) should be considered for a percent expansion. For example, %{n} has the same meaning as %n. The available expansions are:

%n

the name of the current package

%N

the Name of the parent package (the same as %n unless within a SplitOff)

Note: If a parent Package field contains %type_*[], those percent expansion values will be included in %N in a SplitOff block (since they are included in %n in the parent).

%e

the package epoch

%v

the package version. Note that the Epoch is not part of %v.

%V

the full package Version, which automatically includes the Epoch if present. Note that this percent expansion is only available for packages whose InfoN level is at least 4.

%r

the package revision

%f

the full package name (%n-%v-%r). Note that the Epoch is not part of %f.

%p, %P

the prefix where Fink is installed, e.g. /opt/sw. You must not assume all users have Fink installed in /opt/sw; use %p to get the correct path.

%d

the destination directory where the tree to be packaged is built, e.g. /opt/sw/src/fink.build/root-gimp-1.2.1-1. This temporary directory serves as root during the installation phase of compiling a package. You must not assume that root-%f will be in %p/src since a user can change that directory using the Buildpath field in /opt/sw/etc/fink.conf.

%D

the Destination for the parent package (the same as %d unless within a SplitOff)

%i

the full install-phase prefix, equivalent to %d%p

%I

the Install prefix of the parent package, equivalent to %D%P (the same as %i unless within a SplitOff)

%a

the path where the patches can be found. As of fink-0.29.0, this variable should not be used. Use %{PatchFile} to access the .patch file. Support for %a will be removed in the future.

%b

the build directory, e.g. /opt/sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1. You must not assume that %f will be in %p/src since a user can change that directory using the Buildpath field in /opt/sw/etc/fink.conf. The innermost directory is named based on the Source filename, or is the value of the SourceDirectory field (if present), or is not used if NoSourceDirectory is true.

Note: Use this only when there is no other way. The build directory is the current directory when scripts are executed; you should use relative path names in commands.

%c

the parameters for configure: --prefix=%p plus anything specified with ConfigureParams. (The behavior is different when the package has Type: perl; in that case, the default flags for building a perl package are used instead of --prefix=%p in the definition of %c.)

%m

the machine architecture string. This is no longer strictly dictated by the type of machine, but is rather a choice made by the user upon fink installation among those architectures which will run on the user's hardware. Current possible values are 'powerpc' for ppc machines and either 'i386' or 'x86_64' for x86 machines. The choice 'x86_64' is only available if the machine is capable of running 64-bit libraries and executables. (This item was introduced in the fink-0.12 era; the current description is valid for fink-0.29.5 and later.)

%%

the percent character (one that will not be expanded according to whatever follows it). Expansion occurs strictly left-to-right, so %%n is not anything related to the package name, but rather is the string %n. (Introduced in fink-0.18.0)

%type_raw[type], %type_pkg[type], %type_num[type]

pseudo-hashes returning the subtype for the given type. See documentation for the Type field later in this document. The _raw form is the exact subtype string, while the _pkg form has all period characters removed (as per Fink's language-version package naming convention and for other clever uses). (Introduced in a post-0.19.2 CVS version of fink.) The _num form was introduced in fink-0.26.0 and removes all non-digits from the Type field.

Note that when the Type field defines type to be "Boolean", then (%type_pkg[type]) can be used directly in conditional expressions. (Its boolean value is true or false, corresponding to the subtype is being evaluated.)

%{ni}, %{Ni}

the package name invariant portion. These are like %n and %N, except all %type_pkg[] and %type_raw[] are blanked out. (Introduced in a post-0.19.2 CVS version of fink) You should use %{ni} and %{Ni} to avoid confusion with the %n and %N expansions.

%{default_script}

Valid only in PatchScript, CompileScript, and InstallScript fields, the default contents of that type of field. The value is often dependent on the Type field, and is always defined (though it may be blank). When used in the InstallScript of a SplitOff (or SplitOffN), this expansion will yield the parent's default, even though the default for InstallScript in a SplitOff package is blank. (Introduced in fink-0.20.6)

%{PatchFile}

The full path to the file given in the PatchFile field. (Introduced in fink-0.24.12)

%{PatchFileN}

The full path to the file given in the PatchFileN field. (Introduced in fink-0.30.0)

%lib

If Type: -64bit is defined to be -64bit, this expands to lib/ppc64 under the powerpc architecture, and to lib/x86_64 under the i386 architecture (the proper storage locations for 64-bit libraries on 32-bit systems); otherwise, this expands to lib. (Introduced in fink-0.26.0)

Note that %lib is not permitted in the ConfigureParams field unless the InfoN level is at least 4.

Next: 3. Packaging Policy