(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]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)