(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 nt...@debian.org _______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
