[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dual life modules

On Wed, Jan 30, 2013 at 03:48:09PM -0800, Russ Allbery wrote:
> 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.

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
this with the way we're expected to deal with bundled javascript in
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)

Reply to: