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

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



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. :-)

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.

> >   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.

> > 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?
:-)

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpf83NX1Iabl.pgp
Description: PGP signature


Reply to: