Simon McVittie <s...@debian.org> (2024-11-12): > 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?
That should be the case. > 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. 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). > 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? 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). > 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. That'd require double-checking, but if that's indeed the case and nobody picked them up while we weren't looking, sure. > 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. 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). > 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. 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 (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
