Re: dual life modules
On Wed, Jan 30, 2013 at 03:48:09PM -0800, Russ Allbery wrote:
> Niko Tyni <firstname.lastname@example.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.
Hi Russ, all,
I think you've summed up what my underlying instincts are pretty well
here. The desire not to deviate from upstream's handling of dual-lived
modules is really about not introducing surprises, which, in the real
world where code isn't always perfectly compatible with all versions,
is an issue.
(I actually think there's a serious problem along the same lines as
Debian. Even when upstream haven't hacked on the code, they certainly
won't be expecting people to be running a potentially completely
different version of the library than they ship. But I digress.)
I do worry a bit about the action at a distance which can result from
a common library being upgraded owing to one caller needing a newer
version; generally you wouldn't expect installing a new application to
change the libraries being used by an unrelated program, especially not
in a stable release. But I don't really see any way round that.
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)