Vendor profiles allows vendors and users to customize Lintian without having to modify the underlying code. If a profile is not explicitly given, Lintian will derive the best possible profile for the current vendor from dpkg-vendor.
Profile names should only consist of the lower case characters ([a-z]), underscore (_), dash (-) and forward slashes (/). Particularly note that dot (.) are specifically not allowed in a profile name.
The default profile for a vendor is called $VENDOR/main. If Lintian sees a profile name without a slash, it is taken as a short form of the default profile for a vendor with that name.
The filename for the profile is derived from the name by simply concatenating it with .profile, Lintian will then look for a file with that name in the following directories:
$HOME/.lintian/profiles
/etc/lintian/profiles
$LINTIAN_ROOT/profiles
Note that an implication of the handling of default vendor profiles implies that profiles must be in subdirectories of the directories above for Lintian to recognise them.
The directories are checked in the listed order and the first file matching the profile will be used. This allows users to override a system profile by putting one with the same filename in $HOME/.lintian/profiles.
Profiles are written in the same syntax as Debian control files as described in the Debian Policy Manual ยง5.1. Profiles allow comments as described in the Policy Manual.
The fields in the first paragraph are:
Name of the profile.
Name of the (parent) profile, which this profile extends. Lintian will recursively process the extended profile before continuing with processing this profile. In the absence of this field, the profile is not based on another profile.
Comma-separated list of checks. Lintian will ensure all checks listed are loaded (allowing tags from them to be enabled or disabled via Enable-Tags or Disable-Tags).
If a given check was already loaded before this field is processed, then it is silently ignored. Otherwise, the check is loaded and all of its tags are disabled (as if it had been listed in Disable-Tags-From-Check).
This field is most likely only useful if the profile needs to enable a list of tags from a check in addition to any tags already enabled from that check (if any).
Comma-separated list of checks. All tags from each check listed will be enabled in this profile. The check will be loaded if it wasn't already.
Comma-separated list of checks. All tags from each check listed will be disabled in this profile. The check will be loaded if it wasn't already.
Comma-separated list of tags that should be enabled. It may only list tags from checks already loaded or listed in one of the following fields "Load-Checks", "Enable-Tags-From-Check" or "Disable-Tags-From-Check" in the current profile.
Comma-separated list of tags that should be disabled. It may only list tags from checks already loaded or listed in one of the following fields "Load-Checks", "Enable-Tags-From-Check" or "Disable-Tags-From-Check" in the current profile.
The profile is invalid and is rejected, if Enable-Tags and Disable-Tags lists the same tag twice - even if it is in the same field. This holds analogously for checks and the three fields Load-Checks, Enable-Tags-From-Check and Disable-Tags-From-Check.
It is allowed to list a tag in Enable-Tags or Disable-Tags even if the check that provides this tag is listed in the Disable-Tags-From-Check or Enable-Tags-From-Check field. In case of conflict, Enable-Tags / Disable-Tags shall overrule Disable-Tags-From-Check / Enable-Tags-From-Check within the profile.
Load-Checks, Enable-Tags-From-Check and Disable-Tags-From-Check can be used to load third-party or vendor specific checks.
It is not an error to load, enable or disable a check or tag that is already loaded, enabled or disabled respectively (e.g. by a parent profile).
A profile is invalid if it directly or indirectly extends itself or if it extends an invalid profile.
By default the tags from the check "lintian" will be loaded as they assist people in writing and maintaining their overrides file (e.g. by emitting malformed-override). However, they can be disabled by explicitly adding the check lintian in the Disable-Tags-From-Check field.
The fields in the secondary paragraphs are:
Comma separated list of tags affected by this paragraph.
Either "Yes" or "No", which decides whether these tags can be overridden. Lintian will print an informal message if it sees an override for a tag marked as non-overridable (except if --quiet is passed).
The value must be a valid tag severity; the severity of the affected tags is set to this value. Note that experimental is not a severity.
The paragraph must contain at least one other field than the Tag field.