[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Vendor-based customization of Lintian (or profiles)

Hash: SHA256


Considering that #513663 will be closed in 2.5.0~rc3, I figured it was
time to start a new branch. XD
  I was considering to do either Vendor-based customization or support
third party checks (e.g. Lintian "extra"), as the subject suggests I
think I will start with Vendor-based Lintian.
  However if you think third party checks should be given priority, let
me know - this decision is not set in stone. :)

- ------------
The general idea of this has been to allow Debian derivatives or/and
Debian blends to use Lintian without modifying the code.  Currently
Ubuntu has to patch Lintian  every time they import because their
requirements are slightly different than Debians.
  In the past it was just to remove a line of code here or there in the
checks. However, now that the test-suite has been enabled they have also
been required to update some of the tests to match these changes.

If it sounds familiar then it is probably because the particular idea
has been debated before at DebConf10[DC10] (and possibly at other times
and places).

- ------------
This is a list of things that the solution should handle (the "how"-part
comes later).  If you feel the requirements are not reflecting what is
really needed, do object.  These requirements should form the basis for
any suggested solution.

 * No code changes:
   - It must be possible to alter whether Lintian emits a tag without
     modifying code.
 * Re-usable:
   - Most profiles will likely be based on the core profile. New
     profiles should be able to "extend" existing profile.
   - Extended profile must be able to include tags not originally
     in the original profile.
   - Extended profile must be able to exclude tags originally in the
     original profile.
 * Add vendor/3rd party checks [Deferred]:
   - A profile may include new checks/collections not present in the
     Lintian package itself.
 * A tag not included in the current profile shall not be emitted.
   - An override for such a tag is not considered "unneeded" and must be

 * Allow profiles to mark tags as "cannot be overridden"/"not
   - Support FTP-master auto-reject as a profile.
 * Allow profiles to alter severity (but not certainty).
   - What is serious to us may be minor to others.
   - The --display-level argument should operate in terms of active
     profile's severity and not original severity
 * Allow current tag selection command arguments to affect the profile.
   - suppress-tags{,-from-file} suppresses tags even if the current
     profile would have included them.

Rationale for deferring "Add checks": Fixing this is effectively to fix
the "third party checks" problem and this adds complexity like "how to
handle name clashing with checks/collections".  We will have that debate
eventually.  It is my belief that it will be easier for us to add the
third party checks on top on the profile system than the other way
around (infrastructure wise).
  Also, as soon as we add third party checks our current collections as
well as our check interface becomes part of our API.  Changing any of
these could possibly break other packages.

Original solution
- -----------------
The original solution involved tagging each tag with the profiles it was
a part of (mentioned in the follow up for [DC10]).  Personally I think
the solution suffers from a few problems.

 - Users/System admins cannot make their own profile without messing in
   LINTIAN_ROOT/checks/*.desc, which is usually root/root unless you use
   --root (or LINTIAN_ROOT=)/some/where/writable.
 - It does not appear to be easy to extend/reuse an existing profile
   without altering said profile.
 - Vendors may have merge conflicts if profiles are added or extended
   further up in the "food chain".

Proposed solution
- -----------------
We add a new directory to the Lintian root called "profiles" with the


profiles/default would be a symlink to the current default vendor. The
symlink should probably be generated at build time or install time
(probably the former is the easiest).
  The absence of the default symlink should imply debian as default
vendor to keep git clones functional.

Profiles should be specified with a new command line argument --profile
<profile> or the environment/lintianrc variable LINTIAN_PROFILE=<profile>.
  <profile> should be specified as $VENDOR/$profile or $VENDOR.  The
latter being short for $VENDOR/main. The actual file name of the profile
will be $VENDOR/$profile.profile and should be located in:


All of these directories (if they exist) are expected to have the same
layout (as described above).  Profile names cannot contain ".".

Profile file format
- -------------------
The general format is the same as always (same as our desc files or

Profile: <name>
Extends: <profile>
Enable-Check: <check>[, <check2> ...]
Disable-Check: <check>[, <check2> ...]
Enable-Tag: <tag>[, <tag2> ...]
Disable-Tag: <tag>[, <tag2> ...]

All fields are multi-line (except Profile) and newlines are not
significant.  The semantics are:

Profile is required and contains the (machine-readable) name of the
profile; this should be used in the output to identify the chosen profile.

Extends is optional and denotes the profile this profile is based on.
Lintian will recursively process the extended profile before continuing
with processing this profile.  Said profile is located by traversing the
profile directories (as listed above).  In the absence of this field,
the profile is not based on another profile.
  A profile is considered invalid and is rejected if it (in)directly
extends itself.

Enable-Check and Disable-Check are both optional.  They respectively
enable or disable all the tags within checks.  The profile is invalid
and is rejected, if it lists the same check twice - even if it is in the
same field.  However, it is valid to enable or disable a check that was
(respectively) disabled or enabled by a profile extended by profile.
  It is not an error to enable or disable a check that is already
enabled or disabled (respectively).
  Do you think these fields would cause confusion if we later add "third
party checks" support to profile?  Maybe Enable-/Disable-Tags-By-Check
would be a better name for these?

Enable-Tag and Disable-Tag are both optional.  They work analogous to
Enable-Check and Disable-Check except they only affect a single tag.  It
is allowed to allowed to list a tag in Enable-Tag or Disable-Tag even if
the check that provides this tag is listed in the Disable-Check or
Enable-Check field.  In case of conflict, Enable-Tag / Disable-Tag shall
overrule Disable-Check / Enable-Check within the profile.

In the absence of the fields Extends, Enable-Tag, Disable-Tag,
Enable-Check and Disable-Check, the profile shall simply include all
checks/tags known to it.

Possible extensions to this would be to allow patterns in the *-Tag
fields.  A pattern from Disable-Tag overrules a pattern in Enable-Tag.
A specific tag name always overrules a pattern.

Extra Sections
- --------------
As described in the requirements, there are number of optional
requirements that we can look at.  I believe this can be addressed by
extending the above profile format with an optional number of extra

Tag: <tag>[, <tag2> ...]
Overwritable: <yes|no>
Severity: <tag severity>

Tag lists the field affected by this paragraph.  Overwritable denotes
whether or not the tags can be overwritten.  Severity sets the severity
of the listed tags to a known Lintian severity.
  Tag must be present in each of these paragraphs.  At least one of
Overwritable and Severity must be present.

When we agree on (the basis of) an implementation (not necessarily the
one proposed here) I suggest we add it to the Debian wiki under
Lintian/Spec/VendorCustomization (or similar).
  This way the specification does not suddenly get lost on the mailing
list and we can easily update it later.


[DC10] http://lists.debian.org/debian-lint-maint/2010/08/msg00012.html

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: