Re: heads-up, debhelper now depends transitively on libsub-prototype-perl and hence on the current "perlapi"

(adding cc to strip-nondeterminism@pdo and so quoting in full)

On Tue, May 21, 2024 at 12:34:34AM +0100, Peter Green wrote:
> As far as I can tell, until recently all the perl modules that
> debhelper depended on where either part of the perl package itself,
> or were pure perl modules. This meant that changes to "perlapi"
> did not make debehlper uninstallable.
> 
> However, while working on raspbian (which is still dealing with
> the time64 transition), I discovered the following dependency
> chain.
> 
> debhelper
> dh-strip-nondeterminism
> libfile-stripnondeterminism-perl
> libsub-override-perl
> libsub-prototype-perl
> perlapi-<whatever>
> 
> If my understanding is correct, this means that when perlapi is
> bumped debhelper will become uninstabllable. Since almost
> everything in Debian, including libsub-prototype-perl,
> build-depends on debhelper this will present a bit of a
> problem.
> 
> This dependency chain seems to be have been introduced by the
> upload of libsub-override-perl 0.11-1

Thanks for bringing this up. This is indeed a problem, and a blocker
for a future Perl 5.40 transition in Debian. So it should probably
be a release critical bug against something (maybe all of debhelper,
strip-nondeterminism and libsub-override-perl ?)

As seen in #931730 this is not the first time this kind of issue
comes up. Back in 2019 File::StripNondeterminism::handlers::zip was
changed to use Sub::Override instead of the earlier Monkey::Patch
because the latter introduced a similar build cycle.

Getting rid of monkeypatching Archive::Zip altogether as tracked in
 https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/issues/8
would probably be the best fix.

Alternatively, finding yet another way of the monkeypatching
Archive::Zip at runtime would work around this for hopefully
at least another few years :)

Other alternatives would probably require weakening some link of the cycle
by remoting a Depends to a Recommends (and adding graceful handling when
the recommended package is not installed.) 

As a last resort I suppose libsub-prototype-perl *could* be changed to
not use debhelper for building, but that seems to me rather laborious,
fragile and counterproductive.

FWIW it doesn't seem fair to ask Sub::Override upstream to avoid
Sub::Prototype because of this Debian specific issue. But I haven't looked
at how common the new functionality requiring Sub::Prototype really is.

Help would of course be very much appreciated.
-- 
Niko Tyni  [email protected]