Re: dual life modules

[Niko Tyni <ntyni@debian.org>]

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.)

> 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.

Thanks, that makes sense.

I'm still not entirely certain if this value is in balance with the added
maintenance burden and the decreased testing coverage of combinations
with the separate packages installed.

Possibly it is: most of the burden is actually carried by the pkg-perl
team rather than the perl package maintainers, which probably means it
gets shared adequately, and QA issues haven't been a real problem so far.

The maintenance burden is most visible with security updates in dual
life modules, where we need to patch the same code in two packages
(which adds up when the bug is present in multiple suites.) 
Even for regular bug fixes, there's the need for coordinating patches
between the packages, and we don't really have good mechanisms for
automating or verifying that. So it's quite possible that a fixed module
from the perl package will be overridden by an unfixed separate one.

We've also had quite some busywork in the past with pre-release cleanups
of useless versions of dual-life modules and the associated shuffling
of versioned dependencies. Things may have got a bit better this release
cycle due to improved Lintian checks, though.

As for the QA part: if my count is correct, we currently have 35 separate
packages of dual-life modules in sid, and 17 of those are pulled in
by versioned dependencies in other packages. Even without taking the
combinatory explosion into account, this seems to create rather a lot
of chances for the undesired 'action at a distance' Dominic mentioned,
if we actually do worry about the updates breaking things. (FWIW I think
I always considered it an unspoken assumption in this context that such
breakage happens "almost never".)

The concerns about third party code assumptions are rather hard to
quantify, but I may well have underestimated this effect. FWIW, I
think the Fedora folks have already split the modules out. That may tip
the balance a bit in the future as the default set of module versions
everywhere becomes less predictable.

All that said, my opinion may have come out too strongly. I'm not really
pushing any change to the status quo at the moment. Upstream is ejecting
modules out of the perl core at a steady rate, so much of this may well
get solved just by waiting. And I can certainly live with the current
scheme in the meantime.
-- 
Niko Tyni   ntyni@debian.org