Re: Vendor-based customization of Lintian (or profiles)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-04-19 20:23, Neil Williams wrote:
> On Tue, 19 Apr 2011 20:04:47 +0200
> Niels Thykier <niels@thykier.net> wrote:
>
>>> [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.
>
> 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:
>
> http://packages.debian.org/sid/all/emdebian-crush/filelist
>
> 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.
>
Indeed :)
>>> 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
>>> structure:
>>>
>>> profiles/
>>> debian/
>>> main.profile
>>> ftp-auto-reject.profile
>>> ubuntu/
>>> main.profile
>>> $other_vendor/
>>> some.profile
>>> default
>
> 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
applications/build tools.
>>> 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.
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNrdxDAAoJEAVLu599gGRCjkcQAJGuBLAd3Wiuuv2++4VQQPUn
b3Kj1RrTD9tUSXQY/TsJoOngHOY8XMwwpoECn11ZBYsttA26Pi47wokRljpYALEJ
R5KfMgBXOC04F7bxSgof1ZsQY5yuv8srO/tlRZHkSdwgYuNbCj2pSGeTSAPsR6Su
7X7rxJQEijZWTQwxzdZsch2BLXX2P8C0NC4ZlTthjram48Io/r512KBw2Bkn4M04
FTbj4zMWnMbR4uN2fiVmbaC2EgxuF6nc5b2S0nSZA7aGGTX/x/7vFuZ98mgmVCSf
ZDvdeA2C8tOFvShKYfajIOKmni56MBq6YKrrNrbU5IBQLgHCtI3Iiab2oxqTEtp0
lGadM439nkGc8IbBLDmJeB2Z8KffxAhrjDP2gpdkAZYd2mtmtTc9kShEYL7Ra5Rc
2n7T7m41BuKtLjtY6FlQqtZ2nE2+0a3Rgp3/n0nzU6Bjm33KAIx31uAuuHEwMqN+
cBH/3EdVXOBzjL4J+j2++ICX8H1BkMCVvgE+cHbOKfJnls8Z9I8dLOysQ60M3Wyk
w/hfD4T1rSJ8zn4itfuGWfC6uzOh9EkVv77tEPjaIP/mQ/jpkyejqOk9x1dvyIOn
N1Q4k4p9SvHChriVZHQ8JkkHh3APX1oyHhdDoW1eQeVZkM26wAnAK7WwQhg7l9RG
mCDhK8Gfto7IxNRmTiRl
=NHEd
-----END PGP SIGNATURE-----
Reply to: