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 [cjwat...@debian.org]