Re: Vendor-based customization of Lintian (or profiles)
-----BEGIN PGP SIGNED MESSAGE-----
On 2011-04-19 20:23, Neil Williams wrote:
> On Tue, 19 Apr 2011 20:04:47 +0200
> Niels Thykier <firstname.lastname@example.org> wrote:
>>> * 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
> Emdebian tried this and came up against a few hidden assumptions in
> lintian which we discussed with the lintian maintainers at the time. We
> experimented with an emdebian checks file and desc file:
> If this proposal completes the final stage of that process, I will be
> v.happy. :-)
Do you have a link to that debate; unfortunately I believe it was before
my involvement with Lintian, so I do not believe I have seen it (unless
it is covered in the DC10 notes from the BoF).
> Another common requirement at work is to switch off the lintian warning
> about "unsupported distributions" as we're trying to build
> lintian-clean packages for our own internal repositories and it makes
> apt pinning a lot easier to *not* use stable, testing, unstable or any
> of the Debian ToyStory codenames.
> If that can be done with a simple file which applies across all
> packages, it will just be so much easier.
>>> 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).
> That makes the third-party responsible for avoiding clashes - which is,
> IMHO, the way it should work.
Maybe - I am still reluctant to include third party checks in this
specification; partly because the current development has changed the
below mentioned check/collection "API" and partly to keep the "size" of
this specification down.
>>> 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.
>>> Proposed solution
>>> We add a new directory to the Lintian root called "profiles" with the
> I think there should be support for dpkg-vendor in this situation. If
> DEB_VENDOR is defined, lintian can look for that profile. Emdebian has
> been doing this for some time with emvendor but not (yet) with lintian.
>>> Profiles should be specified with a new command line argument --profile
>>> <profile> or the environment/lintianrc variable LINTIAN_PROFILE=<profile>.
> IMHO DEB_VENDOR is a better fit.
Hmm, dpkg-vendor/DEB_VENDOR could be a valid alternative, but I think I
would like to keep LINTIAN_PROFILE as well. This would allow
users/sysadmins to set their own profile that is completely unrelated to
any known vendor without breaking DEB_VENDOR sensitive
>>> 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.
> Any patches?
Unfortunately not at the moment; I wanted a bit of feedback before I
started working on this. But when I start the work, I will push a
branch to the lintian git.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----