-----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 <[email protected]> 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----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
