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

Re: Vendor-based customization of Lintian (or profiles)

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,

[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
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: