Re: RfC: Moving not-pkg-perl-team-specific lintian tests from pkg-perl-tools to lintian proper
On 2015-05-18 17:07, gregor herrmann wrote:
> On Sat, 16 May 2015 19:30:40 +0200, Axel Beckert wrote:
>
>> gregor herrmann wrote:
>>> On Fri, 15 May 2015 21:32:29 +0200, Axel Beckert wrote:
>>>> 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
>>> I'm seeing quite a few false positives with those checks;
>> I assume that you don't include libapp-perl-package-name in that
>> statement. I consider that tag to be quite precise: "Certainty:
>> certain"
>
> Right, I meant the other two.
>
>> With regards to library-package-name-for-application and
>> application-in-library-section, I've set "Certainty: possible"
>
> I'd rather rate it as "wild guess" :)
>
>> But yes, those tests will generate false positives and I currently
>> have no idea how to reduce the amount of false positives noticably.
>
> Me neither, sorry.
>
Based on this remark, I suspect "wild-guess" is indeed better.
Do you think that more data be helpful here? I.e. if we collected a
full run worth of data from lintian.d.o, do you think we could increase
the reliability of the tag?
I must admit that I am a bit concerned about adding (more) wild-guess
tags. They can quickly become a drain on resources because they can
trivially receive a lot of bugs to fix false-positive.
> [...]
> On Sat, 16 May 2015 22:39:15 +0200, Niels Thykier wrote:
>
>>> 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.
>
> Yup.
>
>>> 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.
>
> Well, packages with Module::Build::Tiny would just explode instead of
> build without the fix in debhelper 9.20140227. Currently this is no
> issue as long as a debhelper version >= stable is used but until a
> few weeks ago the then stable version was not enough and the check
> helpful. - Since this still affects potential backports to oldstable
> I would personally keep it.
>
While it is certainly /not/ a blocker, the concern from my PoV is that
the expected life time of these tags are now less than a year and not
relevant to unstable/testing.
Unless the merge (plus release) happens "really soon(tm)", we might be
a in a position where we spend time moving the tag only to find it
obsolete by the time it is deployed.
>>> Check: usr-lib-perl5
>>> Tag: usr-lib-perl5-mentioned
>> Ok. Please:
>> * Chose a more descriptive tag name. Maybe:
>> "mentions-deprecated-usr-lib-perl5-dir"
>
> Hm, deprecated is not exactly true in my understanding, is not used
> anymore.
>
>
> Cheers,
> gregor
>
If it is not used anymore, then perhaps
"mentions-obsolete-usr-lib-perl5" or maybe
"references-unused-usr-lib-perl5" ?
Thanks,
~Niels
Reply to: