Bug#747628: perl: module deprecations / removals in 5.20

[Niko Tyni]

(over-quoting for the benefit of debian-perl)

On Mon, May 12, 2014 at 11:52:31PM +0100, Dominic Hargreaves wrote:
> On Sat, May 10, 2014 at 04:44:14PM +0300, Niko Tyni wrote:
> > Package: perl

> > I'm not quite sure how we should treat those modules that have been
> > removed between 5.18 and 5.20. In #702096 I wrote
> > 
> > > We probably need to package all of these separately. If jessie is going
> > > to release with Perl 5.18, adding them as recommendations to the perl
> > > package should be enough. If we release with something later we probably
> > > need real dependencies for one release cycle.
> > 
> > Now that we're aiming for 5.20 in jessie, do we need to bite the bullet
> > and add the hard dependencies? I sort of think recommendations might
> > be enough after all.
> > 
> > AIUI, the concern is that without the dependencies, users upgrading from
> > wheezy will have their programs silently broken by disappeared modules,
> > as they are skipping those upstream releases with deprecation warnings.
> > But why aren't recommendations adequate for that? Users that have
> > configured apt to ignore recommendations have explicitly indicated that
> > they prefer disk space savings over safety guards, IMO.
> > 
> > The other POV is that upstream manages module removals carefully, making
> > sure that users will see the warnings, and we should be as careful not
> > undermine that.
> > 
> > A full list of relevant removals is
> > 
> >  libarchive-extract-perl 
> >  libb-lint-perl
> >  libcpanplus-perl
> >  libfile-checktree-perl
> >  liblog-message-perl
> >  libmodule-pluggable-perl
> >  libobject-accessor-perl
> >  libpod-latex-perl
> >  libterm-ui-perl
> >  libtext-soundex-perl

> Hmm, for 5.14 we ended up with Depends for the reasons you describe, but
> I think your point is a fair one; Recommends is probably strong enough.
> The other way of looking at it is whether there are situations in which
> having them as Depends would be actively harmful. It does feel slightly
> wrong that we are forcing packages of code which is being explicitly
> removed from core to be installed again on all systems, so I'd be happy
> to go with Recommends in the absence of specific issues which would
> merit Depends.

I test built about 800 out of 2600 Architecture:all modules with 5.19.11,
and I see a few build failures due to these removals.

Log::Message libcpanplus-dist-build-perl_0.76-1_amd64-20140512-1603.build
Log::Message libcpanplus-perl_0.9148-1_amd64-20140512-1604.build
Module::Pluggable libb-lint-perl_1.17-1_amd64-20140512-1247.build
Module::Pluggable libbot-training-perl_0.04-1_amd64-20140512-1305.build

While that's a very small proportion, there aren't any bugs filed about
those even though they currently show up as warnings in the build logs.
This shows we haven't done a full check about the effects of the 5.18
deprecations on the archive yet. We clearly should.

The recent thread on debian-perl about splitting libcatalyst*-perl has
some parallels to this, so I'm copying that list too. I think most people
there agreed that recommendations would be enough to keep user programs
from breaking, as long as any build dependency issues in the archive
are taken care of. Tincho seemed to disagree?

I still think that once the build failures are fixed, Recommends:
should be strong enough.
-- 
Niko Tyni   ntyni at debian.org