On Sat, 02 Nov 2024 at 18:35:53 +0100, Sebastian Ramacher wrote:
> In trixie we will also freeze all packages that produce udebs
Is it straightforward to give packages whose udebs are not yet in active
use a semi-automatic exemption from this freeze, while still applying
other reasons they might be frozen?
I'm thinking mainly of src:gtk+3.0, src:vte2.91 and src:gtk4 here.
We added udebs to those packages a while ago, but they aren't in active
use because the graphical installer is still on GTK 2.
I don't fully understand the hint language, but would a permanent
"unblock-udeb gtk+3.0", etc. for each of the affected packages perhaps
have the desired effect?
I think src:dbus and maybe some of the AT-SPI stack are in a similar
situation: they added udebs a while ago, to unblock the ability to add
accessibility technologies to the graphical installer, but as far as I'm
aware they are not in active use.
I've seen suggestions that the GNOME team should be actively removing the
udebs from gtk+3.0, etc. to take it out of the udeb freeze set, but that
would require going back through NEW (with the associated delays) when
udebs are wanted again, and I'm not sure that's desirable.
Regarding the GTK 2 installer, I have been slowly learning how to test
cdebconf and refactoring it to use a more GTK-3-friendly threading
model, but I can't make any guarantees about when that will be ready for
review/merge or wider testing, and I certainly don't think it will be
production-ready by the end of the calendar year; "early forky cycle"
is probably a more realistic target for a GTK 3 installer.
smcv
