Re: RfC: Moving not-pkg-perl-team-specific lintian tests from pkg-perl-tools to lintian proper
Hi,
one further general thought: I think, I'll first add some of the
improvements suggested in this thread while the checks are still in
pkg-perl-tools.
gregor herrmann wrote:
> On Mon, 18 May 2015 17:35:07 +0200, Niels Thykier wrote:
> > 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:
>
> > >>>> * library-package-name-for-application
> > >>>> * application-in-library-section
>
> > >> 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.
*nod*
> > 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'll let Axel answer this question; personally I'm a bit skeptical
> that more data alone will show anything new;
Actually I think it could help to find some obvious and easy to
whitelist(*) cases I've not yet thought of. Something to add
near "# Big exception list for all tags", "# ignore library $something
tools" or "ignore debhelper plugins" in application-not-library.pm.
> I guess we have to think about the logic a bit more
Improvement at that point is very welcome!
> (currently it basically checks for anything in $PATH).
Which I still think is valid. E.g. it does not check for executables
under e.g. /usr/lib/$pkg or such.
> > 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.
Good point. Nevertheless I don't think that tags where the explicit
suggestion to add an override is included in the long description
should cause too many bugs due to people trying to fix false
positives. (But I may be wrong here. I know that people don't always
read such hints. :-)
> > >>> Check: debhelper (perl-specific)
> > >>> Tag: arch-any-package-needs-newer-debhelper (*)
> > >>> Tag: module-build-tiny-needs-newer-debhelper
[...]
> > 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.
>
> Ok, I see this point about obsolescence.
Lets keep those (debhelper and cdbs checks) in pkg-perl-tools then,
where we can update or remove the tags rather quickly and don't have
to care much about sustainability.
> > >>> 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.
> > If it is not used anymore, then perhaps
> > "mentions-obsolete-usr-lib-perl5" or maybe
> > "references-unused-usr-lib-perl5" ?
>
> I guess 'obsolete' was the word I was looking for in vain :)
> 'references' might be a bit more precise then 'mentions', so, in best
> bikeshedding mode, I'd suggest 'references-obsolete-...' :)
Going once, going twice, sold! :-)
(*) Or is it actually a blacklist? :-)
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: