Re: Vendor-based customization of Lintian (or profiles)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi (again for some)
I realised after sending my proposal that it would probably be a good
idea to (ab)use the d-derivatives list to get more opinions on this
proposal (quoted in full below).
I have set Reply-To to lintian-maint@d.o as I would like the debate on
this topic to stay on the lintian list. The web-archive for the
proposal starts at [1].
Thank you in advance,
~Niels
[1] http://lists.debian.org/debian-lint-maint/2011/04/msg00277.html
On 2011-04-19 18:14, Niels Thykier wrote:
> 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/
iQIcBAEBCAAGBQJNrc69AAoJEAVLu599gGRCilwP/iFzixE+X4zhJJMECWSnX1Px
DV23KR/pRLZHYtekHSDYWAaDaUNyKEkrpRGKPxcU2IyGcq1LOl+mbUm9irWF3uNK
OlOntor5oNkvQV/V+q3bNYGIqY6DckakFGD8lggIyDdxOqf9O2OclKZYHBVA0X0h
RDmtp0PFaBWgPQHjimxcrt6ftrtA7Ap3ulVUnHl1rWs1M24orAyrVzcEcKYa2BKb
ZQjy9aufkaGj06KkBzAems9CrVoNolNqpHgIqRTC53ca8+z3jRFSZjl0VirfABg8
kVzE+HFmrV661tpG1jXv69iPjiorrh7jsu9DdPF4Om1D20hlz+NPCxx19lwF1LsD
OzcxdeJFId1jvmS43q/w9uESozN+TaEAr1wX8oVwf2Y5b+247ceFyKDdn8Ag4kE0
4t5GAuoS3m0T7Hvevo47cERR5cmP3ubru46woqFFUJUayserUqDexI6AwGbhhMnx
DNlGOmUc/X6mhpqBSvSWhneWrT01PyF7urkWjnA4Td6qoxweP6Ruty35bK5VYpys
TCP5z3Ux1um2A8PtGtM7IqHjUjgdalBFAosrXBijiMrNcfsxN66ygQpP2G44nPAR
q9V0xgpWN9ZKadSV7xFUFyQ3aAW0WrvXJw9ktRPHKkuxUKFrY3JCgbZWYeH4XMCF
Pb/ivf6t5qQ2YGOdhOIa
=0+pQ
-----END PGP SIGNATURE-----
Reply to: