WIP: Moving not-pkg-perl-team-specific lintian tests from pkg-perl-tools to lintian proper (was: Re: RfC: ...)
Hi,
JFYI for those not following #debian-qa on IRC or the Debian Perl
Group meetings at DebCamp: I'm currently working on moving some of the
lintian tests included pkg-perl-tools over to lintian proper.
In both package's git repositories, there is a feature branch called
ppt-lc-mover for that:
https://anonscm.debian.org/cgit/lintian/lintian.git/log/?h=ppt-lc-mover
https://anonscm.debian.org/cgit/pkg-perl/packages/pkg-perl-tools.git/log/?h=ppt-lc-mover
Feel free to have a look and comment on it, but be aware that this is
still work in progress.
Niels Thykier wrote:
> On 2015-05-15 21:32, Axel Beckert wrote:
> > * 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".
Thanks for those comments. I've implemented all these suggestions.
The three tags are now available in lintian in the above mentioned
feature branch and have lowered severity and certainty as discussed in
another branch of this thread.
> > 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 ?
Done, too.
> > 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.
I assume you meant check/rules.* and not debian/rules. :-)
I've tried to do so, but there's one big difference between those two
tags which makes it hard to squeeze into the existing scheme in
checks/rules.pm's @GLOBAL_CLEAN_DEPENDS:
* clean-should-be-satisfied-by-build-depends is triggered only upon
specific regexps matching debian/rules' contents.
* libmodule-build(-tiny)-perl-needs-to-be-in-build-depends is
independent from from debian/rules.
So I'll rather try to add
libmodule-build(-tiny)-perl-needs-to-be-in-build-depends to
checks/fields.pm since it's a simple check which only depends on the
presence of some packages in some fields or not.
> > Check: no-perl-modules
> > Tag: depends-on-perl-modules
> >
>
> Yes please. Though please consider the following:
[...]
> > Check: usr-lib-perl5
> > Tag: usr-lib-perl5-mentioned
> >
>
> Ok. Please:
[...]
> > Check: xs-abi
> > Tag: legacy-vendorarch-directory (*)
> >
>
> Ack on this, with the following remarks:
[...]
Those are not yet moved, but planned to be moved, too. Will announce
when I'm ready with them, too.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Reply to: