Package: slic3r Version: 1.2.9+dfsg-6 Severity: serious Tags: buster sid User: debian-p...@lists.debian.org Usertags: perl-5.26-transition X-Debbugs-Cc: p...@packages.debian.org
This package contains a binary ("XS") Perl module /usr/lib/slic3r/auto/Slic3r/XS/XS.so but does not depend on perlapi-*. This is a violation of the Debian Perl policy, quoting: 4.4.2. Binary and Other Architecture Dependent Modules Binary modules must specify a dependency on either perl or perl-base with a minimum version of the perl package used to build the module. Additionally, all binary modules (regardless of their installation directory) and any other modules installed into $Config{vendorarch} must depend on the expansion of perlapi-$Config{debian_abi} using the Config module. If $Config{debian_abi} is empty or not set, $Config{version} must be used. The perlapi-* dependency guarantees that the binary module is compatible with the version of perl on the system. I see the release team tools have spotted this package and scheduled binNMUs for the ongoing Perl 5.26 transition, probably because older versions with the perlapi-* dependency are still around on some architectures. Still, partial upgrades (upgrading perl without upgrading slic3r or vice versa) will result in breakage. The fix is probably something like override_dh_perl: dh_perl /usr/lib/slic3r so that dh_perl knows about the private library directory. Once this is fixed, please file a bug against perl so we can add a Breaks entry for older versions. This makes sure partial upgrades from stretch work. -- Niko Tyni nt...@debian.org