Post by Simon McVittieIn 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?
That should be the case.
Post by Simon McVittieI'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.
TL;DR: Yes to everything you're proposing.
I don't think they've been caught up in the temporary freezes (I'd think
the longest one last cycle was a little week, usually a few days,
sometimes just a few hours), so I've never taken the time to adjust (1)
the hints and (2) the tooling that makes sure the relevant hint files
knows about all udebs. That could be done if we were to have a permanent
udeb freeze (I'm not advocating for that).
Post by Simon McVittieI 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?
Not having a block-udeb gtk3.0 in the first place would be slightly more
straightforward (see https://release.debian.org/britney/hints/freeze
which is usually mostly skipped because of the âfinishedâ near the top,
until I get rid of that line to implement temporary freezes for udebs).
Post by Simon McVittieI 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.
That'd require double-checking, but if that's indeed the case and nobody
picked them up while we weren't looking, sure.
Post by Simon McVittieI'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.
Getting you to undo/redo things looks like a waste of your time and
ftp-master's. Adjusting hints (and hint-side tooling) seems like the
obvious way to go (again, not done until now because that didn't seem
required).
We would also lose installability checks, see:
https://d-i.debian.org/dose/
There we see that a bunch of packages are not installable in unstable,
including at-spi2-core-udeb (via libsystemd0), libvte-2.91-0-udeb and
libgtk-3-0-udeb (via libxcomposite1).
Post by Simon McVittieRegarding 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.
At this point, unless it was ready like right now, the next cycle seems
much better indeed.
And many thanks for looking into that.
Cheers,
--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant