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

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

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.


Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: