Package: perl Version: 5.26.1-3 Severity: minor X-Debbugs-Cc: Colin Watson <cjwat...@debian.org>
I have just noticed that Filter::Util::Call is in both src:perl and libfilter-perl. This seems to warrant some package metadata handling as described below. Colin: copying you as the libfilter-perl maintainer, please let me know if you have any concerns here. The normal implications of a Perl dual life module that's separately packaged in Debian are that the relevant binary packages built from src:perl (currently mostly perl-modules-5.26 and libperl5.26) need to - Provide the same name so that any unversioned reverse dependencies will be satisfied by the Perl core version and don't unnecessarily pull in the separate version - Break older versions of the separate package so that obsolete versions can not potentially override a newer version on the core side (the separate package will always "win" if it's installed because it's first on @INC) - Replace older versions of the separate package so that upgrades will prefer to remove it if necessary However, I see the Perl core only imports part of the Filter CPAN distribution; for instance there's no Filter::Util::Exec. It seems to me that only the Breaks part above is relevant in this case. We need to assume that if libfilter-perl is installed, users will want the extra features not found on the core side. Setting severity to 'minor' as even the need for a Breaks entry seems somewhat theoretical to me: Filter is clearly a somewhat frequently released XS distribution so the perlapi-* dependencies will probably make sure that no obsolete versions stay installable in practice. Adding the Breaks shouldn't hurt though afaics, so I think we should do that for correctness. -- Niko Tyni nt...@debian.org
