Packaging - 6. Reference

The package name. May contain lowercase letters, numbers and the special characters '.', '+' and '-'. No underscores ('_'), no capital letters. Required field.

Percent expansion is applied to this field for %N, %{Ni}, %type_raw[], and %type_pkg[] only.

As per Fink packaging policy, a given package must always compile with the same options enabled. If you have multiple variants for a package (see documentation for the Type field), you must encode the specific variant info into the Package field (see documentation for the %type_pkg[] percent expansion). That way each variant has a unique name the package name indicates which variant option(s) are included. Note that use of the %type_pkg[] and %type_raw[] percent expansions in the Package field is new and severely incompatible with older versions of fink, so such package descriptions must be embedded in a InfoN field with N>=2.

The upstream version number. Same limitations as the Package field. Required field.

Note that some programs use nonstandard version numbering schemes that may cause sorting confusion or that contain characters that are not allowed in this field. In these situations, when writing the Fink package, you must convert the upstream value to one that is acceptable and that allows the versions to be arranged in the correct order. When in doubt about how version strings will be sorted, you can use the dpkg command at a shell prompt. For example,

  dpkg --compare-versions 1.2.1 lt 1.3 && echo "true"

will print "true" because version string "1.2.1" is less than "1.3". See the dpkg manpage for more details.

The package revision. Increase this when you make a new description for the same upstream version. Revision numbers start at 1. Required field.

Fink's policy is that any time you make a change to the .info file that results in changes to the binary (compiled) form of a package (the .deb file), you must increase Revision. This includes changing the Depends or other package lists, and adding, removing, or renaming splitoff packages or shifting files among them. When migrating a package to a new tree (from 10.2 to 10.3, for example) involves such changes, you should increase Revision by 10 (or some other large number) in the newer tree in order to leave space for future updates to the package in the older tree.

A comma-separated list of fink architecture(s) for which the package (and any splitoff packages) are intended. As of fink-0.29.5, the valid values for architecture are powerpc, i386, and x86_64. If this field is present and not blank after conditional handling, fink will ignore the package description(s) if the local fink architecture is not listed. If the field is omitted or the value is blank, all architectures are assumed.

One common use of this field will be for packages which require a compiler earlier than gcc-4.0 (or packages which depend on such packages), which should be declared to have architecture powerpc.

This field supports the standard conditional syntax for any value in the value list and percent-expansions can be used (see the Depends field for more information). In this manner, certain variants can be restricted to certain architectures. For example:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.8 5.10.0)
  Architecture: (%type_pkg[perl] = 5100) x86_64

will result in the field for the foo-pm5100 variant being x86_64 and the field being blank for the foo-pm588 variant. Remember that when the field is blank, all architectures are permitted.

The example above gives a very common use of this field: since some modules for system-perl 5.10.0 on 10.6 do not build as 32-bit (i386), this field allows limiting multiple-type perl packages to specific systems.

A comma-separated list of distribution(s) for which the package (and any splitoff packages) are intended. At present, the only valid values for distribution are 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, and 10.15 . If this field is present and not blank after conditional handling, fink will ignore the package description(s) if the local machine distribution is not listed. If the field is omitted or the value is blank, all distributions are assumed. (Introduced in fink 0.26.0.)

Since Fink's 10.9 through 10.14.5 distributions share a common set of finkinfo files, the most common use of this field will be for packages which are suitable for one of those distributions but not the other.

This field supports the standard conditional syntax for any value in the value list and percent-expansions can be used (see the Depends field for more information). In this manner, certain variants can be restricted to certain distributions. For example:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.12.3 5.12.4)
  Distribution: (%type_pkg[perl] = 5123) 10.7, (%type_pkg[perl] = 5123) 10.8

will result in the Distribution field for the foo-pm5123 variant being 10.7, 10.8 and the field being blank for the foo-pm5124 variant.

Since python 2.5 is not available in the 10.7+ distributions, and the available perl versions vary by distribution, these package types provide a common use of this field. For reference, we note the availabilty of various perl versions in the 10.3 through 13.0 distributions (bolded systems indicate system-perl at that version):

    perl 5.6.0:  10.3
    perl 5.8.0:  10.3
    perl 5.8.1:  10.3, 10.4
    perl 5.8.4:  10.3, 10.4
    perl 5.8.6:  10.3, 10.4, 10.5
    perl 5.8.8:        10.4, 10.5, 10.6
    perl 5.10.0:             10.5, 10.6
    perl 5.12.3:                         10.7, 10.8, 10.9
    perl 5.12.4:                         10.7, 10.8, 10.9
    perl 5.16.2:                         10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13
    perl 5.18.2:                         10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.18.4:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.28.2:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.30.2:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.30.3:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.34.1:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0

A way to include all supported variants in a single finkinfo file is as follows.

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.8 5.10.0 5.12.3 5.12.4 5.16.2)
  Distribution: <<
   (%type_pkg[perl] = 588) 10.6,
   (%type_pkg[perl] = 5100) 10.6,
   (%type_pkg[perl] = 5123) 10.7, (%type_pkg[perl] = 5123) 10.8, (%type_pkg[perl] = 5123) 10.9,
   (%type_pkg[perl] = 5124) 10.7, (%type_pkg[perl] = 5124) 10.8, (%type_pkg[perl] = 5124) 10.9,
   (%type_pkg[perl] = 5162) 10.7, (%type_pkg[perl] = 5162) 10.8, (%type_pkg[perl] = 5162) 10.9
  <<

Note that we do not include old distributions, such as 10.2 or 10.4-transitional, since the versions of fink which are relevant for them do not recognize this field.

Introduced in fink 0.12.0. This optional field can be used to specify the epoch of the package (which defaults to 0 if not specified). For more information refer to the Debian Policy Manual. Because Fink and some of the underlying Debian tools use name-version-revision as the unique identifier of a package, you must not create a package that differs from another solely by its epoch.

When used in a version string, the Epoch appears before the Version value, separated by a colon (1:3.14-2). Note that the Epoch is not part of %v (or (%f). If you add an Epoch field to a package description file, you may have to adjust versioned dependencies on the packages in it. For example, if you add Epoch: 1 and foo-dev declares Depends: foo-shlibs (= %v-%r), you will need to rewrite that as Depends: foo-shlibs (= %e:%v-%r).

A short description of the package (what is it?). This is a one-line description that will be displayed in lists, so it must be short and informative. It should be less than 45 chars and must be less than 60. It is not necessary to repeat the package name in this field - it will always be displayed in proper context. Required field.

This can be set to bundle. Bundle packages are used to group a set of related packages together. They only have dependencies, but no code and no installed files. The fields Source, PatchScript, CompileScript, InstallScript and related ones are ignored for bundle packages.

nosource is a very similar type. It indicates that there is no source tarball, so nothing is fetched and the unpack phase creates just an empty directory. However, the patch, compile and install phases are executed normally. This way you can bring in all the code with a patch, or just create some directories in the InstallScript. Since fink 0.18.0, you can get the same behavior by setting Source: none. This allows you to use "Type" for other purposes (Type: perl, etc.)

Since fink 0.9.5 there is type perl which causes alternate default values for the compile and install scripts to be used. Beginning in fink 0.13.0, there is a new variant of this type, perl $version, where $version is a specific version of perl consisting of three numbers separated by periods, e.g., perl 5.6.0.

Beginning in a CVS version of fink after fink-0.19.2, the language/language-version use has been generalized to allow any Maintainer-defined types and associated subtypes and more than a single type for a given package. The type and subtype are each arbitrary strings of non-whitespace characters (but parentheses, commas, braces, and percent signs should not be used); no percent-expansion is performed, and the type (not subtype) values are converted to all-lowercase. Multiple type values (each with an optional whitespace-separated subtype) are specified in a comma-separated list.

In addition, the concept of "variants" exists, where a single .info file describes a family of related packages with various options enabled. The key to this whole process is the use of a list of subtypes. Instead of a single string, one uses a space-separated list of strings in parentheses. Fink clones the package description file for each subtype in the list and replaces this list with that single subtype. For example:

Type: perl (5.12.3 5.12.4)

yields two package descriptions, one that behaves as if Type: perl 5.12.3 and the other Type: perl 5.12.4. The special subtype list "(boolean)" stands for a list containing the type itself and a period, so the following two forms are identical:

Type: -x11 (boolean)
Type: -x11 (-x11 .)

Subtype list expansion/package cloning is recursive; if there are multiple types with subtype lists, you will get all combinations:

Type: -ssl (boolean), perl (5.12.3 5.12.4)

One can access the specific variant subtype in other fields using the %type_raw[] and %type_pkg[] pseudo-hashes. Here are two example .info fragments:

Info2: <<
Package: foo-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4)
Depends: perl%type_pkg[perl]-core
 <<

Info2: <<
Package: bar%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_raw[-x11] = -x11) x11
CompileScript:  <<
  #!/bin/bash -ev
  if [ "%type_raw[-x11]" == "-x11" ]; then
    ./configure %c --with-x11
  else
    ./configure %c --without-x11
  fi
  make
<<
<<

Starting in fink 0.26.0, there is a special Type: -64bit which controls a new percent expansion %lib and also changes the default value of LDFLAGS. When combined with the new construction %type_num[], this allows a single .info file to build both a 32-bit version of a library and a 64-bit version. Here's some sample code:

Info2: <<
Package: foo%type_pkg[-64bit]
Type: -64bit (boolean)
Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
ConfigureParams: --libdir='${prefix}/%lib'
SplitOff: <<
 Package: %N-shlibs
 Files: %lib/libfoo.*.dylib
 Shlibs: <<
    %p/%lib/libfoo.1.dylib 1.0.0 %n (>= 1.0-1) %type_num[-64bit]
  <<
<<
<<

Note that Type: -64bit is generally not appropriate for the x86_64 architecture, since in that case libraries are being built 64-bit by default and stored in %i/lib.

This field gives the nature of the license under which the package is distributed. The value must be one of the values described in Package Licenses earlier in this document. Additionally, this field must only be given if the package actually complies to the packaging policy in these respects, i.e. a copy of the license is installed in the doc directory for the package.

The name and e-mail address of the person responsible for the package. This field is required, and there must be exactly one name and address in the following format:

Firstname Lastname <user@host.domain.com>

This field allows fink to implement backward-incompatible syntax changes in package description files. A given version of fink is configured with the maximum integer "N" that it can handle. Any package in a higher InfoN field will be ignored, so this mechanism should only be used when necessary, lest people with older versions of fink be needlessly alienated. To use this mechanism, embed the entire package description in the desired InfoN field. See the "File Format" section earlier in this document for a description of the syntax for multiline fields. Here are the features added for each InfoN level, along with the earliest version of fink that supports it:

• Info2 (fink>=0.20.0): Ability to use percent-expansions in the main Package field of the .info file and the ability to use the %type_* percent-expansions in the Package field of SplitOff (and SplitOffN) packages.
• Info3 (fink>=0.25.0): Can indent nicely in .info files, no more support for RFC-822 multi-lines, and can put comments in pkglist fields.
• Info4 (fink>=0.26.2): adds %V expansion, and permits %lib in ConfigureParams field.

A list of packages which must be installed before this package can be built. Percent expansion is performed on this field (as well as the other package list fields in this section: BuildDepends, RuntimeDepends, Provides, Conflicts, Replaces, Recommends, Suggests, and Enhances. Usually, this is just a comma-separated list for plain package names, but Fink now supports alternatives and version clauses with the same syntax as dpkg. A fully featured example:

Depends: <<
	daemonic (>= 20010902-1),
	emacs | xemacs
<<

The layout above is the preferred format for the Depends and similar fields. The field uses the multi-line field declarators << and each package is placed in alphabetical order on its own indented line. If the field only has a single entry, the simplified Field: value format may be used.

Note that there is no way to express real optional dependencies. If a package works both with and without another package, you must either make sure that the other package is not used even when it is present or add it to the Depends field. If you want to offer the user both options, make two separate packages, e.g. wget and wget-ssl.

Order of operations: logical "OR" (list of alternatives) has a higher precedence (binds more tightly) than the logical "AND" between each package (or set of alternatives) in the comma-separated list. Unlike the use of parentheses in arithmetic, there is no way to specify alternative groups of packages or otherwise change the order of operations in Depends and related fields.

Starting with a post-0.18.2 CVS version of fink, you can have conditional dependencies. These are specified by placing (string1 op string2) before a package name. Percent expansion is performed as usual and then the two strings (neither of which can be null) are compared according to the op operator: <<, <=, =, !=, >>, >=. The immediately-following package is only considered as a dependency if the comparison is true.

You can use this format to simplify maintaining several similar packages. For example, the packages elinks and elinks-ssl could both list:

Depends: <<
	expat-shlibs,
	(%n = elinks-ssl) openssl097-shlibs
<<

would have the same effect as having elinks list:

Depends: expat-shlibs

and elinks-ssl list:

Depends: expat-shlibs, openssl097-shlibs

As an alternative syntax, you can also specify (string), which is "true" if string is non-null. For example:

Package: nethack%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_pkg[-x11]) x11

would set the package x11 as a dependency for the nethack-x11 variant but not for the nethack variant.

Note that when using Depends/BuildDepends for shared library packages for which more than one major-version is available, you must not do the following:

  Package: foo
  Depends: id3lib3.7-shlibs | id3lib4-shlibs
  BuildDepends: id3lib3.7-dev | id3lib4-dev

even if your package could work with either library. Pick one (preferably the highest version that can be used successfully) and use it consistently in your package.

As explained in the Shared Library Policy, only one of the -dev packages can be installed at a time, and each has links of the same name that could point to different filenames in the associated -shlibs package. When compiling package foo, the actual filename (in the -shlibs package) gets hard-coded into the foo binary. That means the resulting package needs the specific -shlibs package associated with the -dev that was installed at compile-time. As a result, one cannot have a Depends that indicates that either one will suffice.

In the past, non-essential packages implicitly depended on the essential ones; this is no longer true.

Introduced in fink 0.9.0. A list of dependencies that is applied at build time only. This can be used to list tools (e.g. flex) that must be present to build the package, but which are not used at run time. Supports the same syntax as Depends. If a build is being done with test suites enabled, the dependencies in the TestDepends field will be added to this list.

Introduced in fink 0.32.0. A list of dependencies that is applied at run time only, that is, when the package is being installed. This can be used to list packages that must be present to run the package, but which are not used at build time. Supports the same syntax as Depends.

A comma-separated list of package names that this package is considered to "provide". If a package named "pine" specifies Provides: mailer, then any dependency on "mailer" is considered satisfied when "pine" is installed. You'll usually also want to name these packages in the "Conflicts" and the "Replaces" field.

Note that there is no versioning data associated with Provides items. They do not inherit from the parent package that contains the Provides list nor is there a syntax for specifying an arbitrary version in the Provides field itself. Further, a dependency that contains a version specification is not satisfied by a package that Provides that needed package name. As a result, having many variants provide a common surrogate package may be harmful, because it precludes the use of versioned dependencies. For example, if foo-gnome and foo-nognome both have "Provides: foo", another package with "Depends: foo (> 1.1)" will not work.

A comma-separated list of package names that must not be installed at the same time as this package. For virtual packages it is allowed to list the names of the provided packages here; they will be handled appropriately. This fields also supports versioned dependencies like the Depends field, but not alternatives (wouldn't make sense). If a package is listed in its own Conflicts, it will be (silently) removed from that list. (Introduced in a post-0.18.2 CVS version of fink.)

Note: Fink itself currently ignores this field. However, it is passed on to dpkg and will be handled accordingly. In summary, it only effects run-time, not build-time.

A list of packages that must not be installed while this package is being compiled. This can be used to prevent ./configure or the compiler from seeing undesired library headers or to avoid use of a version of a tool that is known to be broken (for example, a bug in a certain version of sed). If a build is being done with test suites enabled, the packages in the TestConflicts field will be added to this list.

This is used together with "Conflicts", when this package not only takes over the function of the conflicting package, but also has some common files. Without this field, dpkg may generate errors when installing the package because files are still owned by the other package. It is also a hint that the two packages involved are genuine alternatives and one can be removed in favor of the other. If a package is listed in its own Replaces, it will be (silently) removed from that list. (Introduced in a post-0.18.2 CVS version of fink.)

Note: Fink itself currently ignores this field. However, it is passed on to dpkg and will be handled accordingly. In summary, it only effects run-time, not build-time.

These fields specify additional package relations in the same style as the other dependency fields. These three relations don't affect actual installation via dpkg or apt-get. However, they are used by dselect and other frontends to help the user make sensible choices.

A special variation of the Depends field with more strict semantics. This field must only be used after the case has been discussed on the developer mailing list and a consensus has been reached that it is necessary.

A boolean value that denotes essential packages. Essential packages are installed as part of the bootstrap process. dpkg will refuse to remove essential packages from the system unless special flags are used to override this. In the past, non-essential packages implicitly depended on the essential ones; this is no longer true.

Introduced in fink 0.9.9. A boolean value which indicates that no other packages should Depend on this one, they should only BuildDepend. Unlike usual boolean fields, BuildDependsOnly is tri-state: leaving it undefined (not specifying it at all) is different than defining it as logically false. See the Shared Library Policy for more information.

As of fink 0.20.5, the presence or absence of this field, and its value if present, are recorded into the .deb file when the package is built. Therefore, if you change the value of BuildDependsOnly or if you add or remove it, you must increase the revision number of the package.

A list of mirror sites. Each mirror site appears on a separate line, in the following format: <location>: <url>. location can be a continent code (e.g. nam), a country code (e.g. nam-us), or anything else; mirrors are tried in that order. Example:

CustomMirror: <<
nam-US: ftp://ftp.fooquux.com/pub/bar
asi-JP: ftp://ftp.qiixbar.jp/pub/mirror/bar
eur-DE: ftp://ftp.barfoo.de/bar
Primary: ftp://ftp.barbarorg/pub/
<<

The standard continent and country codes are listed in /opt/sw/lib/fink/mirror/_keys, which is part of the fink or fink-mirrors package.

An URL to the source tarball. It should be a HTTP or FTP URL, but Fink doesn't really care - it just passes the URL to wget. This field supports a special URL scheme for mirrors: mirror:<mirror-name>:<relative-path>. This will look up the mirror setting for mirror-name in Fink's configuration, append the relative-path part and use that as the actual URL. The known mirror-names are listed in /opt/sw/lib/fink/mirror/_list, which is part of the fink or fink-mirrors package. Alternatively, using custom as the mirror-name will cause Fink to use the CustomMirror field. Before the URL is used, percent expansion takes place. Remember that %n includes all %type_ variant data, so you may want to use %{ni} here (perhaps with some specific %type_ expansions).

Since fink 0.18.0, Source: none has the special meaning that there is no source to fetch. See the description of the Type field for more information. The value gnu is a shorthand for mirror:gnu:%n/%n-%v.tar.gz; gnome is a shorthand for mirror:gnome:stable/sources/%n/%n-%v.tar.gz. The default is %n-%v.tar.gz (i.e. a manual download). This implicitly-defined Source form is deprecated (explicitly-stated simple filename/manual download is still okay).

Sources that are only needed in order to run test suites should use TestSource and related fields, inside the InfoTest block.

If a package consists of several tarballs, name them with these additional fields, starting with N = 2. So, the first tarball (which should be some kind of "main" tarball) goes into Source, the second tarball in Source2 and so on. The rules are the same as for Source, only that the "gnu" and "gnome" shortcuts are not expanded - that would be useless anyway. Starting with a CVS version of fink after 0.19.2, you may use arbitrary (not necessarily consecutive) integer values of N >= 2. However, you still may not have duplicates.

Must be used when the tarball expands to a single directory, but the directory's name is different from the basename of the tarball. Usually, a tarball named "foo-1.0.tar.gz" will produce a directory named "foo-1.0". If it produces a directory with a different name, specify it with this parameter. Percent expansion is performed on this field.

Set this boolean parameter to a true value if the tarball does not expand to a single directory. Usually, a tarball named "foo-1.0.tar.gz" will produce a directory named "foo-1.0". If it just unpacks the files to the current directory, use this parameter and set it to a boolean true value.

Normally, an auxiliary tarball will be extracted in the same directory as the main tarball. If you need to extract it in a specific subdirectory instead, use this field to specify it. Source2ExtractDir corresponds to the Source2 tarball, as one would expect. See ghostscript, vim and tetex for examples of usage.

This field can rename a source tarball on the fly. This is useful if for example the version of the source is encoded in the directory name on the server, but the tarball itself has the same name for all versions, e.g. http://www.foobar.org/coolapp/1.2.3/source.tar.gz. To circumvent the problems caused by this, you would then use something like

SourceRename: %n-%v.tar.gz

In the above example this would result in the tarball being stored under /opt/sw/src/coolapp-1.2.3.tar.gz as one would expect.

This is just the same as the SourceRename field, except that it is used to rename the tarball specified by the corresponding SourceN field. See context or hyperref for examples of usage.

Introduced in fink 0.10.0. With this field you can specify the MD5 checksum of the source file. This information is then used by Fink to detect incorrect source files, that is, tarballs not matching the one the package creator used. Common causes for this problem include: incompletely downloaded tarballs; upstream maintainers silently replaced a tarball; a trojan or similar attacks; and so on.

A typical usage example looks like this:

Source-MD5: 4499443fa1d604243467afe64522abac

To compute the checksum, the md5sum tool is used. If you want to determine the checksum of the tarball /opt/sw/src/apache_1.3.23.tar.gz, you run the following command (displayed with output here):

fingolfin% md5sum /opt/sw/src/apache_1.3.23.tar.gz 
4499443fa1d604243467afe64522abac  /opt/sw/src/apache_1.3.23.tar.gz

As you can see, the value to the left is exactly the value you need.

Introduced in fink 0.10.0. This is just the same as the Source-MD5 field, except that it is used to specify the MD5 checksum of the tarball specified by the corresponding SourceN field.

Alternative method to list the checksum for a source file. This field takes a hash type, followed by the actual checksum. For example:

Source-Checksum: SHA256(5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56)

Current valid checksums are MD5, SHA1, and SHA256. The shasum tool can be used to calculate SHA checksums:

$ shasum -a 256 /opt/sw/src/libexif-0.6.22.tar.xz 
5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56  /opt/sw/src/libexif-0.6.22.tar.xz

The Source-Checksum field should only be used once per .info file. If both the Source-MD5 and Source-Checksum fields are present, Source-Checksum takes precedence.

This is just the same as the Source-Checksum field, except that it is used to specify the checksum of the tarball specified by the corresponding SourceN field.

Introduced in fink 0.10.0. This field only applies to source files that are using the tar format

With this field you can rename files in the given source tarball during the extraction of the tarball. This is very useful to work around the fact that the HFS+ file system is not case sensitive, as files like install and INSTALL will collide on a standard Mac OS X system. With this field you can avoid these issues without having to repackage the tarball (as was done in the past in such cases).

In this field you simply specify a list of files that are to be renamed. You can make use of wildcards. By default any given file will be renamed to its current name with _tmp appended. You can override this default by using the same syntax as in the Files and DocFiles fields, namely by writing the old filename followed by a : and then followed by the new filename. Example:

TarFilesRename: foo bar.* qux:quux
Tar2FilesRename: directory/INSTALL:directory/INSTALL.txt

Introduced in fink 0.10.0. This is just the same as the TarFilesRename field, except that it is used for the tarball specified by the corresponding SourceN field.

A boolean value. If true, the files config.guess and config.sub in the build directory will be replaced with versions that know about Darwin. This happens in the patch phase and before the PatchScript is run. Only use this when you know it is necessary, i.e. when the configure script fails with a "unknown host" message.

Introduced in a post-0.9.0 CVS version. A list of subdirectories. This does the same as UpdateConfigGuess, but is useful for packages that have outdated config.guess files in several directories throughout the source tree. Previously you had to copy/move the files there manually in the PatchScript. With this new field you can just list the directories. Use . to update files in the build directory itself.

A boolean value. If true, the files ltconfig and ltmain.sh in the build directory will be replaced with versions that know about Darwin. This happens in the patch phase and before the PatchScript is run. Only use this when you know that the package needs it. Some packages can be broken by overwriting the libtool scripts with mismatching versions. See the libtool page for further information.

Introduced in a post-0.9.0 CVS version. A list of subdirectories. This does the same as UpdateLibtool, but is useful for packages that have outdated libtool 1.3.x scripts in several directories throughout the source tree. Previously you had to copy/move the files there manually in the PatchScript. With this new field you can just list the directories. Use . to update files in the build directory itself.

A boolean value. If true, the file Makefile.in.in in the subdirectory po is replaced with a patched version. This happens in the patch phase and before the PatchScript is run.

The patched version respects DESTDIR and makes sure that message catalogs end up in /opt/sw/share/locale, not /opt/sw/lib/locale. Before using this field, make sure that you won't break the package and that it's really required. You can run diff to find the differences between the package's version and Fink's version (in /opt/sw/lib/fink/update).

The filename of a patch to be applied with patch -p1 <patch-file. This should be just a filename; the appropriate path (the same directory where the .info file is located) will be prepended automatically. Percent expansion is performed on this field, so a typical value is simply %f.patch or %n.patch. The patch is applied in a separate step before the PatchScript is run (if any).

Remember that %n includes all %type_ variant data, so you may want to use %{ni} here (perhaps with some specific %type_ expansions). It's easier to maintain a single patchfile and then make variant-specific changes in PatchScript than to have a separate patchfile for each variant.

As of fink-0.29.0, this field should not be used. Use PatchFile instead. Support for Patch will be removed in the future.

The same syntax as the Patch field. The full path to this file is available using the %{PatchFile} percent expansion--do not use %a to access this file. Unlike Patch, PatchFile is applied as part of PatchScript. Fink checks that the listed file exists, is readable, and that its checksum matches the PatchFile-MD5 field.

You may not use both Patch and PatchFile in the same package description. Any package that uses PatchFile must declare at least BuildDepends: fink (>= 0.24.12). Giving a higher version requirement is allowed if it is necessary for other reasons.

If a package has several patch files, name them with these additional fields, starting with N = 2. So, the first patch file goes into PatchFile, the second patch file in PatchFile2 and so on. Any package that uses PatchFileN must declare at least BuildDepends: fink (>= 0.30.0). Giving a higher version requirement is allowed if it is necessary for other reasons.

The MD5 checksum of the file given in the PatchFile field. This field is required if PatchFile is used. (Introduced in fink-0.24.12)

The MD5 checksum of the file given in the PatchFileN field. This field is required if PatchFileN is used. (Introduced in fink-0.30.0)

A list of commands that are run in the patch phase. This is the place to put commands that patch or otherwise modify the package source. See the note on scripts below. Before the commands are executed, percent expansion takes place. If a PatchFile field exists, the default PatchScript is:

patch -p1 < %{PatchFile}

If one or more PatchFileN fields are used, the following is appended as needed to the default script:

patch -p1 < %{PatchFileN}

If there is no PatchFile, the default is blank. If you have an explicit PatchScript, you must apply the PatchFile(s) explicitly.

Causes certain environment variables to be set in the compile and install phases. This can be used to pass compiler flags etc. to configure scripts and Makefiles. Currently supported variables are: CC, CFLAGS, CPP, CPPFLAGS, CXX, CXXFLAGS, DYLD_LIBRARY_PATH, JAVA_HOME, LD, LDFLAGS, LIBRARY_PATH, LIBS, MACOSX_DEPLOYMENT_TARGET, MAKE, MFLAGS, MAKEFLAGS. The value you specify is subject to the percent expansion described in the last section. A common example:

SetLDFLAGS: -Wl,-strip_dead_dylibs

Some environment variables have default preset values. If you specify a value for one of these, it will be prepended to the default value. The preset variables (and their default values) are:

CPPFLAGS: -I%p/include
LDFLAGS: -L%p/lib

Starting in fink 0.26.0, there is one exception to these defaults: if Type: -64bit is set to -64bit, then the default value of LDFLAGS is -L%p/%lib -L%p/lib instead.

Finally, MACOSX_DEPLOYMENT_TARGET is set to a default value depending on which version of OSX is being run, but setting a value for it for a package will override (rather than prepend to) the default value.

When set to a true value, deactivates the default values for the preset variables (such as CPPFLAGS, LDFLAGS, CXXFLAGS mentioned above). For example, if you want LDFLAGS to remain unset, specify NoSetLDFLAGS: true .

When set to a true value, appends -jN, where N is the value from the fink.conf field MaxBuildJobs, to the environment variable MAKEFLAGS during CompileScript and TestScript. This value is added to MAKEFLAGS even if the field NoSetMAKEFLAGS: true is used. As of fink > 0.31.2, if the field is not present or blank, the default is True.

In fink >= 0.33.0, when set to a false value, causes fink to build as root rather than as the underprivileged fink-bld user. If this field is not present, its value defaults to true, indicating that the package should be built as fink-bld.

In earlier fink versions, this field does nothing.

Additional parameters to pass to the configure script. (See CompileScript for details.) For packages not of Type: Perl, the parameter --prefix=%p is prepended to this value. As of fink > 0.13.7, this field will also work with perl modules Type: Perl; the default perl Makefile.PL string is prepended to the value supplied for ConfigureParams.

If a build is being done with test suites enabled, the value of the TestConfigureParams field will be appended to the normal ConfigureParams value.

Starting in fink-0.22.0, this field supports conditionals. The syntax is the same as that used in the Depends and other package-list fields. The conditional expression only applies to the whitespace-delimited "word" immediately following it. For example

Type: -x11 (boolean)
ConfigureParams: --mandir=%p/share/man (%type_pkg[-x11]) --with-x11 --disable-shared

will always pass the --mandir and --disable-shared flags, but only pass --with-x11 in the -x11 variant.

This field supports placing parameters into multiple lines using multi-line field declarators. The field is handled as a shell command line and uses \ to separate lines:

ConfigureParams: <<
	--mandir=%p/share/man \
	(%type_pkg[-x11]) --with-x11 \
	--disable-shared
<<

Note: do not place conditional parameters as the last line when using the multi-line field format. In instances when the conditional evaluates as false, the parameter immediately following is not evaluated and this breaks the shell.

This field specifies the GCC-ABI used by C++ code in this package. (It is needed because that ABI has changed twice, and any libraries which you link to containing C++ code must be compiled with the same ABI you are currently using.)

The allowed values are: 2.95.2 (or 2.95), 3.1, 3.3, and 4.0. Our understanding is that the GCC authors intend to stabilize the GCC-ABI at some point; we can hope that it won't change again.

The GCC field does not have a default value, per se, since it is ignored if it is not set. However, for each tree, there is an expected value for GCC corresponding to the default g++ compiler for that tree. The expected values for the various package trees are: 2.95 in the 10.1 tree, 3.1 in the 10.2 tree, 3.3 in the 10.2-gcc3.3, 10.3, and 10.4-transitional trees, and 4.0 in the 10.4 and 10.7 trees.

Note that when the GCC value is different from the expected value, the compiler must be specified within the package (typically by setting the CC or CXX flags), and a dependency on one of the (virtual) gcc packages should be specified.

As of fink 0.13.8, when this flag is present, the version of gcc is tested using gcc_select, and fink exits with an error if the wrong version is present.

This field was added to fink to aid maintainers in tracking the transition between the gcc compilers, which introduced a binary incompatibility between libraries that involve C++ code which is not reflected in the versioning scheme.

A list of commands that are run in the compile phase. This is the place to put commands that configure and compile the package. See the note on scripts below. Before the commands are executed, percent expansion takes place. Normally the default is:

./configure %c
make

This is appropriate for packages that use GNU autoconf. For packages with of type perl (as specified via the Type field) with the perl version not specified, the default instead (as of fink 0.13.4) is:

perl Makefile.PL PREFIX=%p \
 INSTALLPRIVLIB=%p/lib/perl5 \
 INSTALLARCHLIB=%p/lib/perl5/darwin \
 INSTALLSITELIB=%p/lib/perl5 \
 INSTALLSITEARCH=%p/lib/perl5/darwin \
 INSTALLMAN1DIR=%p/share/man/man1 \
 INSTALLMAN3DIR=%p/share/man/man3 \
 INSTALLSITEMAN1DIR=%p/share/man/man1 \
 INSTALLSITEMAN3DIR=%p/share/man/man3 \
 INSTALLBIN=%p/bin \
 INSTALLSITEBIN=%p/bin \
 INSTALLSCRIPT=%p/bin
make
make test

If the type is perl $version with the version specified (e.g., $version might be 5.6.0), then the default becomes:

perl$version Makefile.PL \
 PERL=perl$version PREFIX=%p \
 INSTALLPRIVLIB=%p/lib/perl5/$version \
 INSTALLARCHLIB=%p/lib/perl5/$version/$perlarchdir \
 INSTALLSITELIB=%p/lib/perl5/$version \
 INSTALLSITEARCH=%p/lib/perl5/$version/$perlarchdir \
 INSTALLMAN1DIR=%p/share/man/man1 \
 INSTALLMAN3DIR=%p/share/man/man3 \
 INSTALLSITEMAN1DIR=%p/share/man/man1 \
 INSTALLSITEMAN3DIR=%p/share/man/man3 \
 INSTALLBIN=%p/bin \
 INSTALLSITEBIN=%p/bin \
 INSTALLSCRIPT=%p/bin
make
make test

where $perlarchdir is "darwin" for versions 5.8.0 and earlier, and is "darwin-thread-multi-2level" for versions 5.8.1 and later.

Introduced in fink > 0.13.7. A boolean value, specific for perl module packages. If true, the make test portion of the CompileScript will be ignored for that specific perl module package.

Introduced in fink 0.25. This field encapsulates information that will only be used when performing a build with test suites enabled. It contains other fields. If present, this field must contain a TestScript. All other fields are optional. The following fields are allowed inside InfoTest:

• TestScript: A script which runs the test suite. This script should exit with status 0 if the suite passes, 1 to indicate warnings, or any other value to indicate failures serious enough to be considered fatal. Because of this tri-state logic, you should explicitly set an exit value in this script. For instance, make check is a bad script, since it will exit with status 1 if the check target doesn't exist. make check || exit 2 would be a better script.
• TestConfigureParams: A value which will be appended to ConfigureParams.
• TestDepends and TestConflicts: Lists of packages that will be added to the BuildDepends or BuildConflicts lists.
• TestSource: Extra sources necessary to run the test suite. All of the affiliated fields are also supported, so you must also specify TestSource-MD5 or TestSource-Checksum, and you may also have TestSourceN and corresponding TestSourceN-MD5, TestSourceN-Checksum, TestTarFilesRename, etc.
• TestSuiteSize: Describes approximately how long the test suite takes to run. Valid values are small, medium, and large. This field is currently ignored.
• Any other standard field. If a field is specified both inside and outside InfoTest, the value inside InfoTest will replace the other value when test suites are active.

Here's an example:

InfoTest: <<
    TestScript: make check || exit 2
    TestConfigureParams: --enable-tests
<<

Introduced in fink 0.9.5. A boolean value, specific for perl module packages. If true, this will add code to the install, postrm and postinst scripts that maintains the .pod files provided by perl packages. This includes adding and removing the .pod date from the central /opt/sw/lib/perl5/darwin/perllocal.pod file. (If the type has been given as perl $version with a specific version of perl such as 5.6.0, then these scripts are adapted to deal with the central .pod file /opt/sw/lib/perl5/$version/perllocal.pod.)

A list of commands that are run in the install phase. This is the place to put commands that copy all the necessary files into the temporary dpkg directory for the package. See the note on scripts below. Before the commands are executed, percent expansion takes place. Normally the default is:

make install prefix=%i

The default is appropriate for packages that use GNU autoconf. For packages with of type perl (as specified via the Type field) with the perl version not specified, the default instead (as of fink 0.13.4) is:

make install INSTALLPRIVLIB=%i/lib/perl5 \
 INSTALLARCHLIB=%i/lib/perl5/darwin \
 INSTALLSITELIB=%i/lib/perl5 \
 INSTALLSITEARCH=%i/lib/perl5/darwin \
 INSTALLMAN1DIR=%i/share/man/man1 \
 INSTALLMAN3DIR=%i/share/man/man3 \
 INSTALLSITEMAN1DIR=%i/share/man/man1 \
 INSTALLSITEMAN3DIR=%i/share/man/man3 \
 INSTALLBIN=%i/bin \
 INSTALLSITEBIN=%i/bin \
 INSTALLSCRIPT=%i/bin

If the type is perl $version with the version specified (e.g., $version might be 5.6.0), then the default becomes:

make install INSTALLPRIVLIB=%i/lib/perl5/$version \
 INSTALLARCHLIB=%i/lib/perl5/$version/$perlarchdir \
 INSTALLSITELIB=%i/lib/perl5/$version \
 INSTALLSITEARCH=%i/lib/perl5/$version/$perlarchdir \
 INSTALLMAN1DIR=%i/share/man/man1 \
 INSTALLMAN3DIR=%i/share/man/man3 \
 INSTALLSITEMAN1DIR=%i/share/man/man1 \
 INSTALLSITEMAN3DIR=%i/share/man/man3 \
 INSTALLBIN=%i/bin \
 INSTALLSITEBIN=%i/bin \
 INSTALLSCRIPT=%i/bin

where $perlarchdir is "darwin" for versions 5.8.0 and earlier, and is "darwin-thread-multi-2level" for versions 5.8.1 and later.

If the package supports it, it is preferably to use make install DESTDIR=%d instead.

Introduced in a post-0.23.1 version. This field installs the specified application bundle(s) into %p/Applications. It will also create a symlink to the /Applications/Fink directory. Example:

AppBundles: build/*.app Foo.app

Introduced in fink 0.10.0. This field is somewhat similar to DocFiles. It installs the specified jar files into %p/share/java/%n. Example:

JarFiles: lib/*.jar foo.jar:fooBar.jar

This will install all the jars that were in the lib directory and will install foo.jar as fooBar.jar.

It also ensures that these jar files (specifically: all files in %p/share/java/%n that end in .jar) are added to the CLASSPATH environment variable. This allows tools like configure or ant to properly detect the installed jar files.

This field provides a convenient way to install README or COPYING files in the doc directory for the package, %p/share/doc/%n. The value is a space-separated list of files. You can copy files from subdirectories of the build directory, but they will end up in the doc directory itself, not in a subdirectory. Shell wildcards are allowed. It is also possible to rename single files on the fly by appending the new name separated by a colon (:), e.g. libgimp/COPYING:COPYING.libgimp. This field works by appending appropriate install commands to the InstallScript.

Introduced in fink 0.11.0. This field declares the shared libraries which are installed in the package. There is one line for each shared library, which contains the -install_name of the library and information about its binary compatibility. Shared libraries that are "public" (i.e., provided for use by other packages) have, separated by whitespace after the filename, the -compatibility_version, versioned package dependency information specifying the Fink package which provides this library at this compatibility version, and the library architecture. (The library architecture may either be "32", "64", or "32-64", and may be absent; if absent, the value defaults to "32" under the powerpc and i386 machine architectures, and to "64" under the x86_64 machine architecture.) The dependency should be stated in the form foo (>= version-revision) where version-revision refers to the first version of a Fink package which made this library (with this compatibility version) available. The Shlibs declaration amounts to a promise from the maintainer that a library with this name and a -compatibility_version of at least this number will always be found in later versions of this Fink package. Shared libraries that are "private" are denoted by an exclamation mark preceeding the filename, and no compatilibity or versioning information is given. See the Shared Library Policy for more information.

Introduced in fink 0.10.0. This field provides a convenient way to set environment variables to some static value at runtime (if you need more flexibility, refer to the profile.d scripts section). As long as your package is installed, these variables will be set via the /opt/sw/bin/init.[c]sh scripts.

The value of your variable can contain spaces (trailing ones are trimmed); also, percent expansion takes place. For example:

RuntimeVars: <<
 SomeVar: %p/Value
 AnotherVar: foo bar
<<

will set two environment variables 'SomeVar' and 'AnotherVar' and their values will be respectively '/opt/sw/Value' (or whatever your prefix is) and 'foo bar'.

This field works by appending appropriate commands to the InstallScript. These commands add a setenv/export line for each variable to the package profile.d scripts, so you can provide your own ones, they won't be overwritten. The lines are prepended to the scripts, you can thus use these variables in your scripts.

Introduced in fink 0.9.9. Generate a second package from the same compile/install run. For details about how this works, see the separate splitoff section below.

Introduced in fink 0.9.9. This is the same as SplitOff, used to generate a third, fourth, etc. package from the same compile/install run. Starting with a CVS version of fink after 0.19.2, you may use arbitrary (not necessarily consecutive) integer values of N >= 2. However, you still may not have duplicates.

Introduced in fink 0.9.9. Used only within a SplitOff or SplitOffN field, this designates which files and directories should be moved from the parent package's installation directory %I to the current installation directory %i. Note that this is executed after the InstallScript and the DocFiles of the parent package, but before the InstallScript and Docfiles of the current package.

These fields specify pieces of shell scripts that will be called when the package is installed, upgraded or removed. Fink automatically adds the shell script header #!/bin/sh, and calls set -e so any command that fails will result in instant termination of the script. Fink also adds an exit 0 at the end. To indicate an error, exit from the script with a non-zero exit code. The first parameter ($1) is set to a value indicating what action is being performed. Some possible values are install, upgrade, remove and purge. Note that there are more values, used during error rollback or when removing a package in favor of another one.

The scripts are called at the following times:

• PreInstScript: When the package is installed for the first time and before upgrading the package to this version.
• PostInstScript: After unpacking and setting up the package.
• PreRmScript: Before the package is removed or upgraded to a later version.
• PostRmScript: After the package was removed or upgraded to a later version.

To make it more clear, an upgrade invokes both the ...Inst scripts of the new version and the ...Rm scripts of the old version. Details can be found in the Debian Policy Manual, Chapter 6.

Percent expansion is performed on the scripts. Commands can generally be called without giving a full path.

A space-separated list of files that are user-modifiable configuration files. Percent expansion is performed on this field. The files must be specified with an absolute path, e.g. %p/etc/%n.conf. The named files will receive special treatment by dpkg. When a package is upgraded and the file has changed both on disk and in the package, the user is asked which version to use and backups of the file will be made. When a package is "remove"d, the configuration files will remain on disk. Only a "purge" also removes the configuration files.

Lists the names of Info documents that the package installs in %p/share/info. This will add appropriate code to the postinst and prerm scripts to maintain the Info directory file, dir.

Note: Only use the un-numbered file in the case of split Info documents. E.g. if a package has:

foo.info
foo.info-1
foo.info-2

you should only use:

InfoDocs:  foo.info

This feature is still in flux, more fields for finer control may be added in the future.

Gives a service description for daemonic. daemonic is used by Fink to create and remove StartupItems for daemon processes (e.g. web servers). The description will be added to the package as a file named %p/etc/daemons/name.xml, where name is specified by the DaemonicName field and defaults to the package name. Percent expansion is performed on the contents of this field. Note that you must add daemonic to the dependency list if your package uses it.

A name for the daemonic service description file. See the description of DaemonicFile for details.

The URL of the upstream home page of the package.

A more detailed description than the one in the Description field (what is it, what can I use it for?). Multiple lines allowed. Because this field will be displayed without the benefit of word-wrap, you should manually insert line breaks in order to keep lines less than 79 chars (if possible).

This is for information that is needed to use the package (how do I use it?). As in "run wmaker.inst once before using WindowMaker". Multiple lines allowed. Because this field will be displayed without the benefit of word-wrap, you should manually insert line breaks in order to keep lines less than 79 chars (if possible).

Notes about the packaging. Stuff like "patches the Makefile to put everything in place" goes here. Multiple lines allowed.

Notes that are specific to porting the package to Darwin. Stuff like "config.guess and libtool scripts are updated, -no-cpp-precomp is necessary" goes here. Multiple lines allowed.