On Sat, Jan 02, 2021 at 08:22:48AM +0100, intrigeri wrote: > Hi, > > Dominic Hargreaves (2020-11-10): > > On Tue, Nov 10, 2020 at 09:03:42AM +0100, intrigeri wrote: > >> Dominic Hargreaves (2020-11-09): > >> > A year on, it seems there's almost no realistic prospect of this > >> > package coming back. Shall we remove it from sid? > >> > >> Thank you for caring! > >> > >> Quoting the plan I proposed #912860: "I intend to remove libgtk2-perl > >> from testing soon after the Buster release, and then from sid later > >> during the Bullseye development cycle". > > > We're quite a way through the bullseye development cycle already but > > I guess you mean once we're into the deep freeze when there is no longer > > any chance of reviving those packages for bullseye, which makes sense > > to me. > > Actually, when writing my previous message here, I misread my own > initial proposal. You're indeed correct that under this proposal, > we could remove libgtk2-perl from sid right away. Thank you for > your patience! :) > > Given the upcoming freeze, I'd like to give the maintainers of the > reverse-dependencies a last chance to get their package in Bullseye > before migration of new source packages to testing is disabled > (2021-02-12), which would be required if we removed libgtk2-perl and > all its reverse-dependencies right away. > > In particular: > > - tinyca: a few months ago the maintainer was actively working on > a solution > > - gprename: upstream ported to GTK 3, now waiting for the new release > to be packaged & uploaded > > So, I'm now leaning towards removing libgtk2-perl and its remaining > reverse-dependencies from sid at any time after 2021-02-12 (I don't > care much when exactly). At that point, indeed it'll be too late for > these packages to go into Bullseye, and their maintainers will have > 2 years to find a solution. > > Does this make sense to you?
Sure, sounds good!