Bug#942135: Сannot install Perl 5.30.0-6 without deleting the libgtk2-perl package

[Dominic Hargreaves]

On Tue, Nov 10, 2020 at 09:03:42AM +0100, intrigeri wrote:
> Hi,
> 
> 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".
> 
> In principle, I see value in sticking to the announced timeline, in
> order to lower the risk of bad feelings in case any of the
> reverse-dependencies' maintainers somehow relied on it.
> 
> In practice, if we removed libgtk2-perl now, I would not expect any
> trouble about:
> 
>  - asciio (#912870): I filed a RFH, the maintainer won't have time to
>    do the work themselves
> 
>  - gprename (#912880): no reply from maintainer since 2 years
>    despite 2 pings
> 
>  - tinyca (#912889): the maintainer is actively working on a solution
> 
>  - libdata-treedumper-renderer-gtk-perl (#912874): maintained by
>    pkg-perl, only reason why I did not remove it from sid yet is asciio
> 
> However, wrt. libcircle-fe-gtk-perl (#932220), the brief discussion
> I had with Andrej at DebConf19 suggests it's a touchy topic.
> If someone else, who wants to speed up the removal, takes the lead
> here: great (and please check with Andrej). Otherwise, personally I'd
> rather avoid the extra effort, and simply stick with the originally
> announced timeline.

Thanks for the summary. I got the wrong impression from this
bug and didn't spot the merged bugs at all :(

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.

Cheers
Dominic