Bug#884401: perl: should Break old versions of libfilter-perl
Niko Tyni
ntyni at debian.org
Thu Dec 14 20:27:24 UTC 2017
Package: perl
Version: 5.26.1-3
Severity: minor
X-Debbugs-Cc: Colin Watson <cjwatson at 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 ntyni at debian.org
More information about the Perl-maintainers
mailing list