Bug#711644: Bug#702096: Bug#711644: libcolor-library-perl: FTBFS with perl 5.18: uses modules deprecated in 5.18

Niko Tyni ntyni at debian.org
Mon Jun 10 15:43:34 UTC 2013


On Sun, Jun 09, 2013 at 11:51:28PM +0100, Dominic Hargreaves wrote:
> On Sun, Jun 09, 2013 at 11:32:40PM +0300, Niko Tyni wrote:

> > I suspect the 5.18 perl packages shouldn't Provide virtual packages for
> > the deprecated modules. But I'm rather tired and may well be missing
> > something.
> 
> Yes, I think you're right, and I've been confused today. I thought that
> we had kept/added Provides and Replaces for deprecated modules, but git
> history differs. Of course in this case, libmodule-pluggable-perl was
> already Provided.

AFAICS for the 5.12 deprecations we added Provides entries in 5.10.1-13
and removed them in 5.12.2~rc1-1.

> However, I'm now confused because debian/t/control.t complains about
> Breaks without corresponding Replaces/Provides. I looked back in the
> git history and in (for example) 5.12.1-1 we didn't Break the modules
> being deprecated, but wouldn't we prefer the versions with warnings than
> older versions of the same modules without?

This was probably the first time that already separately packaged modules
were deprecated, so the Breaks entries weren't needed earlier so we
didn't think of them?

Anyway: yes, I think we should Break them and patch debian/t/control.t
accordingly.

This suggests that we should make the test use the list of
deprecated packages in lib/deprecate.pm so that we don't
have to maintain two separate lists. Maybe make
%DEBIAN_PACKAGES a package variable and then access the list
via something like
 require deprecate; my @packages = %deprecate::DEBIAN_PACKAGES
-- 
Niko Tyni   ntyni at debian.org



More information about the pkg-perl-maintainers mailing list