Fink:Policy:Validation

The Fink Validator

The fink validate command is a tool that checks .info (package description) and .deb (compiled binary) package files for compliance with aspects of Fink Packaging Policy and also detects a variety of common packaging mistakes. Before placing a package on the package submissions tracker, you must make sure the .info you submit and the .deb resulting from it have no validation warnings or errors.

If you are just getting starting as a package maintainer, some of the tests may seem arbitrary or excessively nit-picky. The validator is not designed to annoy you (the maintainer) to create un-necessary work, or as a power trip for fink admins, but rather to catch packages that are likely to cause problems for users. They are implemented as a direct result of commonly-observed mistakes in submissions and breakage or general annoyance discussed on the various mailing lists and other venues.

If you are having difficulty solving a validation message, look at other packages similar to yours that validate cleanly. There are usually a variety of solutions to any given problem, depending on the type of package, the user-friendliness of the upstream compiling scripts, etc. Feel free to ask on the mailing lists or IRC channel if you need help.

Newly-Implemented Tests

New tests are created as necessary. Fink admins, developers who handle the package submissions queue, and other users may be running a prerelease version of the fink program that has tests not present in the release version. If someone tells you about a problem in one of your packages as a result of a validation test you don't have, please attempt to fix it. You can't be faulted for not knowing earlier, but...now you know about it. Our goal is to keep the supported fink distributions up to the latest validation standards.

In addition to checks for new features in new fink versions, the following generally-applicable new tests may not be present in all released versions of fink yet:

• The syntax of "Depends" (and similarly-formatted fields) is now checked more strictly.
• There shouldn't be a field named "InfoN".
• "dummy" is not a valid key in the "Type" field.
• We check for a common misuse of the -framework flag in a pkg-config (.pc) data file. This is usually a bug in the upstream version.
• If there are texinfo documentation files, they must be declared in an "InfoDocs" field so that they are linked into the table of contents.
• Different language-version variants of perl and python libraries (-pyXX and -pmXXX packages) must be completely orthogonal; no two variants can have any files in common. Users must be able to install multiple variants concurrently without having conflicts.
• Installed files must not contain references to the pathnames where they were compiled. There are new tests for this problem relevant to compiled python modules (among other filetypes).