Bug#622888: lintian overrides should support more precise pattern matching
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi
I have looked a bit on this and ...
* Allowing "*" anywhere in the extra will help a lot but is not enough.
- some tags might only be emitted on certain architectures and will
therefore cause unused-override on all other architectures
- See #622888
* I do not like <pkg>:$arch as the name of an override file.
* dh_lintian is "smarter" than it documents as far as I can tell.
particularly it actually looks for d/<pkg>.lintian-overrides.$arch,
so using <pkg>.$arch might confuse maintainers or at least require a
versioned B-D on debhelper >= $new_version.
So, I am proposing the following solution:
* Allow "*" anywhere in extra to match any characters
- possibly use ** as any character and * as any non-slash character
- Text::Glob does not quote work for this, but a hand-crafted
glob2regex should not be hard if it is only * (and **) with no
escape (that is no "\* => literal *").
* Allow type + architecture specific tags in override files. Lintian
should ignore all overrides not for this type and architecture.
- Absence of type or architecture should be assumed to be "current
type/architecture" (status quo)
- architecture can be any valid Debian architecture including the
currently accepted wild-cards (e.g. linux-any etc.)[1]
(I have cleverly stolen the proposal of both Steve + Andreas, reworded
to my own proposal and totally claim credit for it >.>)
Looking at a new syntax for overrides to handle overrides; my perl-fu
tells me that currently we look for:
<name>[ <type>]: <tag>[ <extra> ...]
Where <name> is the name of the package/processable, <type> is optional,
but if given one of binary, udeb, source or changes.
As far as I can tell, <type> is redundant in the override file and
unless we allow overrides for other types in the same file I do not see
this changing it. On a related note; that is exactly how I see us
handling "override changes tags" by putting them in the source override.
However that is a different bug (specifically: #575400)
Anyhow, Andreas suggested (in #622888) that we used:
<name>[:<arch>][ <type>]: <tag>[ <extra> ...]
- or -
<name>[ \[<arch-pattern>\]][ <type>]: <tag>[ <extra> ...]
(I added the [ <type>] part, because we need them for backwards
compatibility).
<arch> would be a specific architecture (or possibly one of the
architecture wild-cards. e.g. linux-any) and \[<arch-pattern>\] appears
to be similar to the architecture specific Build-Depends (modulo comma,
I guess)? Personally if we go with the B-D-like version I would have it
follow the same rules.
As for the actual implementation I am preferring the B-D-like one
because it allows for negation and it is not even new to maintainers (or
it should not be, at least).
On the glob issue, I am thinking on going for * -> .* replacement and
then (somehow) quote the rest of the "extra" field.
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNtZ6lAAoJEAVLu599gGRCyE8P/18Kwo7NBAoSU2vjv7YGheuz
Us8eU8KoeccfkJooXOBjfF8654qxyjwmo8k9x/Io1RAodswEZihdmmv+dXoKXKkq
byoSitqe6WVZEHWmbMWCTd5ZDCIzO00gy+20z0KXo539r4j+d3WrmWrB3RtoBZtD
kFsmm4jpiYCGNEbdvdaXLjXlJcW+yWUSZLS8+1AMEL2mK/e9bIBrN/UsROsRyPou
mmFoePREzWfbNTfG1Kj/AwcDmN4i7yYnzW0f7KHzRWqcyYMemNr2cgcGDy+iCQda
x5KuCjkqcISC5PaSaBUZ6sDsSJWXcRQOPItnepATLPY0EpgPDUZ6kyAuNDSWxsSo
uTJ2g7q/jyhq4MtULgl6oGE3c5ImmDZjR04QIp5aHfTH8C+SDyfD2AxKVy0zAUpY
L+j4YfYSvEvm+ZDW0leUkIT3DP73VDptv30hiNY6RB2Og0YJU7VTrfrWZNVfHrFL
4ELm9UzQx+r7DNicVEsvx2i6mHlSSsiPSxcj0H8rJbNak/EpTechDptT3C82q4Es
0RkpZ76qkGdxQ0UPS60ba+f22vfLVFmpuexiQNxgUu/vpmRNAsCrVRi6B16J2u/s
idXrZ/O8HqrDdSWU0jOlweXLkI1A0fYRPslSTj8jHMp8Ltfg6MyUMe8FGFtEJq2k
aJrsUFQn5mUr4s4N/Kz/
=+Doj
-----END PGP SIGNATURE-----
Reply to: