-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi (again for some)
I realised after sending my proposal that it would probably be a good idea to (ab)use the d-derivatives list to get more opinions on this proposal (quoted in full below). I have set Reply-To to [email protected] as I would like the debate on this topic to stay on the lintian list. The web-archive for the proposal starts at [1]. Thank you in advance, ~Niels [1] http://lists.debian.org/debian-lint-maint/2011/04/msg00277.html On 2011-04-19 18:14, Niels Thykier wrote: > Hi > > Considering that #513663 will be closed in 2.5.0~rc3, I figured it was > time to start a new branch. XD > I was considering to do either Vendor-based customization or support > third party checks (e.g. Lintian "extra"), as the subject suggests I > think I will start with Vendor-based Lintian. > However if you think third party checks should be given priority, let > me know - this decision is not set in stone. :) > > > Introduction > ------------ > The general idea of this has been to allow Debian derivatives or/and > Debian blends to use Lintian without modifying the code. Currently > Ubuntu has to patch Lintian every time they import because their > requirements are slightly different than Debians. > In the past it was just to remove a line of code here or there in the > checks. However, now that the test-suite has been enabled they have also > been required to update some of the tests to match these changes. > > If it sounds familiar then it is probably because the particular idea > has been debated before at DebConf10[DC10] (and possibly at other times > and places). > > > Requirements > ------------ > This is a list of things that the solution should handle (the "how"-part > comes later). If you feel the requirements are not reflecting what is > really needed, do object. These requirements should form the basis for > any suggested solution. > > [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. > > [Optional/Extra/Ideas] > * Allow profiles to mark tags as "cannot be overridden"/"not > overwritable". > - Support FTP-master auto-reject as a profile. > * Allow profiles to alter severity (but not certainty). > - What is serious to us may be minor to others. > - The --display-level argument should operate in terms of active > profile's severity and not original severity > * Allow current tag selection command arguments to affect the profile. > - suppress-tags{,-from-file} suppresses tags even if the current > profile would have included them. > > > 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). > 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. > > Original solution > ----------------- > The original solution involved tagging each tag with the profiles it was > a part of (mentioned in the follow up for [DC10]). Personally I think > the solution suffers from a few problems. > > - Users/System admins cannot make their own profile without messing in > LINTIAN_ROOT/checks/*.desc, which is usually root/root unless you use > --root (or LINTIAN_ROOT=)/some/where/writable. > - It does not appear to be easy to extend/reuse an existing profile > without altering said profile. > - Vendors may have merge conflicts if profiles are added or extended > further up in the "food chain". > > > 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 > > profiles/default would be a symlink to the current default vendor. The > symlink should probably be generated at build time or install time > (probably the former is the easiest). > The absence of the default symlink should imply debian as default > vendor to keep git clones functional. > > Profiles should be specified with a new command line argument --profile > <profile> or the environment/lintianrc variable LINTIAN_PROFILE=<profile>. > <profile> should be specified as $VENDOR/$profile or $VENDOR. The > latter being short for $VENDOR/main. The actual file name of the profile > will be $VENDOR/$profile.profile and should be located in: > > ~/.lintian/profiles/ > /etc/lintian/profiles/ > $LINTIAN_ROOT/profiles/ > > All of these directories (if they exist) are expected to have the same > layout (as described above). Profile names cannot contain ".". > > Profile file format > ------------------- > The general format is the same as always (same as our desc files or > debian/control): > > Profile: <name> > Extends: <profile> > Enable-Check: <check>[, <check2> ...] > Disable-Check: <check>[, <check2> ...] > Enable-Tag: <tag>[, <tag2> ...] > Disable-Tag: <tag>[, <tag2> ...] > > > All fields are multi-line (except Profile) and newlines are not > significant. The semantics are: > > Profile is required and contains the (machine-readable) name of the > profile; this should be used in the output to identify the chosen profile. > > Extends is optional and denotes the profile this profile is based on. > Lintian will recursively process the extended profile before continuing > with processing this profile. Said profile is located by traversing the > profile directories (as listed above). In the absence of this field, > the profile is not based on another profile. > A profile is considered invalid and is rejected if it (in)directly > extends itself. > > Enable-Check and Disable-Check are both optional. They respectively > enable or disable all the tags within checks. The profile is invalid > and is rejected, if it lists the same check twice - even if it is in the > same field. However, it is valid to enable or disable a check that was > (respectively) disabled or enabled by a profile extended by profile. > It is not an error to enable or disable a check that is already > enabled or disabled (respectively). > Do you think these fields would cause confusion if we later add "third > party checks" support to profile? Maybe Enable-/Disable-Tags-By-Check > would be a better name for these? > > Enable-Tag and Disable-Tag are both optional. They work analogous to > Enable-Check and Disable-Check except they only affect a single tag. It > is allowed to allowed to list a tag in Enable-Tag or Disable-Tag even if > the check that provides this tag is listed in the Disable-Check or > Enable-Check field. In case of conflict, Enable-Tag / Disable-Tag shall > overrule Disable-Check / Enable-Check within the profile. > > In the absence of the fields Extends, Enable-Tag, Disable-Tag, > Enable-Check and Disable-Check, the profile shall simply include all > checks/tags known to it. > > Possible extensions to this would be to allow patterns in the *-Tag > fields. A pattern from Disable-Tag overrules a pattern in Enable-Tag. > A specific tag name always overrules a pattern. > > Extra Sections > -------------- > As described in the requirements, there are number of optional > requirements that we can look at. I believe this can be addressed by > extending the above profile format with an optional number of extra > paragraphs: > > Tag: <tag>[, <tag2> ...] > Overwritable: <yes|no> > Severity: <tag severity> > > Tag lists the field affected by this paragraph. Overwritable denotes > whether or not the tags can be overwritten. Severity sets the severity > of the listed tags to a known Lintian severity. > Tag must be present in each of these paragraphs. At least one of > Overwritable and Severity must be present. > > > 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. > > ~Niels > > [DC10] http://lists.debian.org/debian-lint-maint/2010/08/msg00012.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNrc69AAoJEAVLu599gGRCilwP/iFzixE+X4zhJJMECWSnX1Px DV23KR/pRLZHYtekHSDYWAaDaUNyKEkrpRGKPxcU2IyGcq1LOl+mbUm9irWF3uNK OlOntor5oNkvQV/V+q3bNYGIqY6DckakFGD8lggIyDdxOqf9O2OclKZYHBVA0X0h RDmtp0PFaBWgPQHjimxcrt6ftrtA7Ap3ulVUnHl1rWs1M24orAyrVzcEcKYa2BKb ZQjy9aufkaGj06KkBzAems9CrVoNolNqpHgIqRTC53ca8+z3jRFSZjl0VirfABg8 kVzE+HFmrV661tpG1jXv69iPjiorrh7jsu9DdPF4Om1D20hlz+NPCxx19lwF1LsD OzcxdeJFId1jvmS43q/w9uESozN+TaEAr1wX8oVwf2Y5b+247ceFyKDdn8Ag4kE0 4t5GAuoS3m0T7Hvevo47cERR5cmP3ubru46woqFFUJUayserUqDexI6AwGbhhMnx DNlGOmUc/X6mhpqBSvSWhneWrT01PyF7urkWjnA4Td6qoxweP6Ruty35bK5VYpys TCP5z3Ux1um2A8PtGtM7IqHjUjgdalBFAosrXBijiMrNcfsxN66ygQpP2G44nPAR q9V0xgpWN9ZKadSV7xFUFyQ3aAW0WrvXJw9ktRPHKkuxUKFrY3JCgbZWYeH4XMCF Pb/ivf6t5qQ2YGOdhOIa =0+pQ -----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]
