Vendor-based customization of Lintian (or profiles)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi
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. :)
Introduction
- ------------
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).
Requirements
- ------------
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.
[Needed]
* 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
ignored.
[Optional/Extra/Ideas]
* Allow profiles to mark tags as "cannot be overridden"/"not
overwritable".
- 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
structure:
profiles/
debian/
main.profile
ftp-auto-reject.profile
ubuntu/
main.profile
$other_vendor/
some.profile
default
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:
~/.lintian/profiles/
/etc/lintian/profiles/
$LINTIAN_ROOT/profiles/
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
debian/control):
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
paragraphs:
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.
~Niels
[DC10] http://lists.debian.org/debian-lint-maint/2010/08/msg00012.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNrbTgAAoJEAVLu599gGRC7XYQAIT9ornGwaGt6h0f0OsL4t60
uv1S19XLeodROvEV303LsspCpt37sxy/GW2K4rzHRB6ziwVWpiigF0cTYB/CBoU3
zaP9XldoRQSNnYNT0Bq4bdnxCpmGaSCPb2g4qoQ3WbvxuAlWeut1Lj6E8hT9opxo
TAud+WOeX2ncGQ+C4NDdMCay+yRRVUUwrIgJC99WbIf7/cj+46Bkgrfwjpfk/6jW
fqpc1TyfDxyxUDcBRUhduu3JwLd4wMV3KjDOMuFVFPRCW27yMrNFkABmPaKa72L5
mSNCdm3NXkaYZA2JpH0q1HM75uorjcTR1Wg3eJO43xfb3sGgRw9bGM6qVkBJA9iF
iFXpwGm/JTMIPtsvkRg1xEcdFRfv2Y8d5rpXSXRQm+G+/F5ctmmSf4N3XG7MnQxp
RlXF7rcbGlRrI0C9jk19v22YReeQOjDCshUexNCMtdwIWtYCrp+GEIYD9b+BaP6E
iHjc6veJDnCbDtzcVLjrcfqc4XKyTdYwwfAtI3CP1pGMIjc9lTy5esZpCImo7+aM
zJGYppZEByZigOEdUAwFvTcQoWNBaOgk83Tc6Tr5vZT7B81POg9Y1iaSqESkpEz6
W6XHrTkPl0mMSIBhrmUStlx0j84lsNLvnbuklmct94/Fe5bHrLorQPHJfHG2y6sY
3Ws1onFINfIqBxw6sVOS
=poAB
-----END PGP SIGNATURE-----
Reply to: