Re: RfC: Moving not-pkg-perl-team-specific lintian tests from pkg-perl-tools to lintian proper
On 2015-05-15 21:32, Axel Beckert wrote:
> Hi,
>
> I intent to move some lintian tests currently used by the Debian Perl
> Team an packaged in the pkg-perl lintian profile shipped with
> pkg-perl-tools into lintian.
>
> [...]
I had a quick look today. I admit having skimmed over the ".desc" files
rather quickly and I have not looked at the severity/certain details.
>
> My main movation is to get the check application-not-library with the
> following tags into lintian:
>
> * libapp-perl-package-name
> * library-package-name-for-application
> * application-in-library-section
>
> This check actually already supports also python and ruby libraries.
>
These 3 tags looks reasonable at first glance. A couple of remarks
about the implementation:
* Use of "grep" in boolean context => Please us "any" from
List::(More?)Util
* Unused capture groups in regexes
* Assumes fields are defined (e.g. "Section"). Please use the two
argument from of $info->field to get a default value if unset or
explicitly check for it being undef.
* The anchoring of "libs" in the regex checking the "Section" fields
does not account for (e.g.) "non-free/libs".
> Looking through the other checks, I'd consider the following tests
> also useful for others:
>
> Check: cdbs (perl-specific)
> Tag: arch-any-package-needs-newer-cdbs (*)
> Tag: module-build-tiny-needs-newer-cdbs
>
I believe Jonas already raised concerns about these.
> Check: debhelper (perl-specific)
> Tag: arch-any-package-needs-newer-debhelper (*)
> Tag: module-build-tiny-needs-newer-debhelper
>
I presume the same issue holds for these.
> Check: module-name
> Tag: no-module-name-in-description (*)
>
Ok - it /might/ make sense to turn into a binary check and merge into
the "description"-check.
Maybe: perl-module-name-not-mentioned-in-description ?
> Check: modulebuild
> Tag: libmodule-build-perl-needs-to-be-in-build-depends
> Tag: libmodule-build-tiny-perl-needs-to-be-in-build-depends
>
It seems to be exactly the purpose of
clean-should-be-satisfied-by-build-depends to test this, so perhaps we
can extend existing tag here.
I realise the implementation of the existing tag works differently (it
also scans the rules file), so perhaps just reuse the tag name and move
the code into d/rules.
> Check: no-perl-modules
> Tag: depends-on-perl-modules
>
Yes please. Though please consider the following:
* Perhaps use implies('perl-modules') instead of matches(...)
* Given the implementation also checks "negative-dependencies", perhaps
the tag should be renamed.
* You probably want to hard code an exception for the perl source
package.
> Check: usr-lib-perl5
> Tag: usr-lib-perl5-mentioned
>
Ok. Please:
* Chose a more descriptive tag name. Maybe:
"mentions-deprecate-usr-lib-perl5-dir"
* Clean up the (unused) imports
* Standardise on "a->property" without empty () following the method
name. I cannot remember if our perlcritic/perltidy setup is
enforcing this, but I believe it was the style we were going for.
> Check: xs-abi
> Tag: legacy-vendorarch-directory (*)
>
Ack on this, with the following remarks:
* Consider using "$proc->pkg_arch" instead of
"$info->field('architecture')". I cannot remember off-hand if
lintian can actually cope with this field being missing, but I
prefer that $info->field is generally used in a way that handles
missing fields.
* Please load "Dpkg::Version" unconditionally. We load it
unconditionally in a different check anyway.
* Another instance of "unused capture groups".
> [...]
> Regards, Axel
>
Side note: As noted in #660733, our reporting framework is now capable
of re-scanning all packages in the archive. Once you have the basics
down, we can pull them to lindsay.d.o and do a trial run. A couple of
items to keep in mind though:
* It will take lintian 3+ weeks to process all packages at its current
rate. We can speed it up a bit by doing an extra processing run
(without updating the website).
* Unreleased tags should generally be experimental if we do this.
We have gotten a complaint or two from people frustrated by lintian
in the archive not producing the same result as the one on
lintian.d.o.
Thanks,
~Niels
Reply to: