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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org