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:
pgpS9Is9N3IdP.pgp
Description: PGP signature