Bug#884401: perl: should Break old versions of libfilter-perl
Colin Watson
cjwatson at debian.org
Thu Dec 14 23:03:52 UTC 2017
On Thu, Dec 14, 2017 at 10:27:24PM +0200, Niko Tyni wrote:
> 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
Just libperl5.26, I think - perl-modules-5.26 has Filter::Simple, but
that's not in the Filter distribution.
> - 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.
I agree with your analysis. We could split out Filter::Util::Call into
a separate binary package built by libfilter-perl and do the full
Provides/Breaks/Replaces thing just on that, but that seems overly
pedantic to me and probably not really necessary.
--
Colin Watson [cjwatson at debian.org]
More information about the Perl-maintainers
mailing list