Re: dual life modules
Niko Tyni <ntyni@debian.org> writes:
> In general, our handling of dual life modules isn't really optimal IMO.
> We shouldn't really be shipping the core versions of dual life modules
> at all if there's a separate package available, but rather make the core
> 'perl' packages depend on the separate ones. (Possibly excluding any in
> perl-base due to its 'Essential' status.)
> The main problem with this is that it breaks the expectation of perl
> 5.X.Y giving you the particular versions of dual life modules released
> upstream with 5.X.Y (as documented by Module::Corelist, for instance.)
> So far, I've taken the conservative approach of not deviating from
> upstream by breaking that expectation.
I believe the current Debian behavior provides a valuable feature that
would be lost by doing what's described above, namely that when using a
straight perl install, one gets by default the modules that have been
incorporated into the core release and heavily tested accordingly.
In some cases, dual-life modules may break or tweak things in subsequent
releases outside of Perl core. In some cases, those changes could
possibly break third-party code. I suspect most third-party code that
uses core modules is heavily tested with the versions that come with Perl
and not as heavily tested with other versions from CPAN. The current Perl
packaging setup arranges for the user to get the core version of a module
unless there's some specific reason to reach for a different version. My
feeling is that this keeps our users in the most heavily tested track by
default, which is valuable.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: