Re: Updates to the trixie freeze policy

Cyril Brulebois <[email protected]> Wed, 13 Nov 2024 04:11:44 +0100
Newsgroups	gmane.linux.debian.devel.gtk-gnome,gmane.linux.debian.devel.release,gmane.linux.debian.devel.boot
Organization	Debian
Message-ID	<[email protected]>
Simon McVittie <[email protected]> (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 ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc (application/pgp-signature, 833 B)