Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Felix Lechner <felix.lechner@lease-up.com>]

Hi,

I also committed another fix, which I found more appropriate after
discussing the issue with Moo's author. The commit message has more
details and is replicated below.

Also, please let us know if your chroot or cowbuilder environment had
libclass-xsaccessor-perl installed. (Note the XS in the name; there
are other similar packages in the archive.)

    https://salsa.debian.org/lintian/lintian/commit/b951f0d4d83fa76286d1f4bd5836cf256038f31c

Kind regards,
Felix Lechner

* * *

Clarify boolean return value in Collect::Binary->is_pkg_class. (Closes: #943724)

According to Moo's author haarg, Moo optionally looks for
Class::XSAccessor,  which in turn requires a argument to be passed to a
writer.

The undef return value is interpreted as providing the wrong number of
arguments. Moo's behavior is documented here:

    https://metacpan.org/pod/Moo#MOO-AND-CLASS::XSACCESSOR

The availability of Class::XSAccessor determines who sees the bug. The
module was probably installed automatically in the chroot and
cowbuilder environments that gave gise to the bug report.

This can be tested: The error also occurs in logrotate/3.15.1-1 in
Debian stable when libclass-xsaccessor-perl is installed.

Thank you to intrigeri for shedding light on the issue and for
putting forward this merge request:

    https://salsa.debian.org/lintian/lintian/merge_requests/266

Contrary to the fix proposed there, which forces the value returned to
a scalar in the consuming package, this commit causes ->is_pkg_class
to return 0 instead of undef (which evaluates to an empty list in list
context).

The undef return value is interpreted as providing the wrong number of
arguments in the mechanics behind the accessor _set_is_dummy.

Thanks to ilmari on #perl-help for identifing the proper fix and for
explaining the issue.

As an aside, installing libclass-xsaccessor-perl has another effect in
Lintian. It causes the style tests for POD coverage to fail:

    ===(   15295;22  33/?  34/?  159/?  97/?  67/?   4/19  0/?  0/?
... )===#   Failed test 'Lintian::Lab is covered'
    #   at t/scripts/pod-coverage.t line 52.
    # Coverage for Lintian::Lab is 50.0%, with 2 naked subroutines:
    #   basedir
    #   keep
    #   Failed test 'Lintian::Processable::Group is covered'
    #   at t/scripts/pod-coverage.t line 52.
    # Coverage for Lintian::Processable::Group is 66.7%, with 7 naked
subroutines:
    #   binary
    #   buildinfo
    #   changes
    #   lab
    #   name
    #   source
    #   udeb
    #   Failed test 'Lintian::Processable::Pool is covered'
    #   at t/scripts/pod-coverage.t line 52.
    # Coverage for Lintian::Processable::Pool is 66.7%, with 3 naked
subroutines:
    #   groups
    #   lab
    #   unpacker
    # Looks like you failed 3 tests of 19.
    t/scripts/pod-coverage.t ........................... Dubious, test
returned 3 (wstat 768, 0x300)
    Failed 3/19 subtests

The error that gave rise to the original bug report was:

    Usage: Lintian::files::empty_package::_set_is_dummy(self,
newvalue) at /usr/share/lintian/checks/files/empty-package.pm line 42.
    internal error: cannot run files check on package
binary:logrotate/3.15.1-1/amd64
    warning: skipping check of binary:logrotate/3.15.1-1/amd64

Clarifies the boolean return type to avoid problems with Moo attribute
accessors.