Transition entanglement: delay glibc upload?

[Simon Chopin]

Hi Steve,

> On Tue, Jan 23, 2024 at 02:02:15AM -0800, Simon Chopin wrote:
> > Hi Release Team,
>
> > It seems we have a few big transitions either in progress (perl,
> > python) or about to start in the coming weeks (php, armhf 64bit time_t).
> > My original plans for glibc would add fuel to that fire, as I projected
> > to upload it to -proposed in about 2 weeks.
>
> You use the past tense here;
> https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649 shows
> glibc 2.39 for this week.  Did this projection change, and in which
> direction?

I though I'd scheduled it for next week, that's my bad. If you prefer I
stick to the announced plan I can probably do it for Friday, though.

> FWIW I've just added 64-bit time_t onto the page, estimating that it will
> start to happen next week.  There are some externalities there not directly
> under our control, specifically the timing of the upload of dpkg to unstable
> and the analysis of the uploads to experimental (which are currently in
> progress) with respect to usrmerge.  I had asked about making sure the perl
> and python transitions complete before 64-bit time_t lands in noble, because
> I don't want these to overlap; and my intention is to turn off Debian
> autosyncs if necessary until perl and python migrate.  But I don't think
> there's the same concern about glibc (it's just a new upstream version with
> new symbols rather than a transition), so I'm not going to argue for
> postponing either glibc 2.39 or 64-bit time_t to avoid entanglement.
>
> > A possible way to reduce the friction introduced by a new glibc verison
> > would be to delay it until after Feature Freeze: fewer packages would
> > pick up the new symbols and thus wouldn't get blocked waiting for the
> > glibc rdeps autopkgtests to clear.
>
> > I can see a couple of downsides to that approach:
>
> > * Fewer packages would pick the new ABIs, which presumably bring in some
> >   sort of improvement in one form or another.
>
> "presumably" - usually, the new symbols from one release to the next are
> small and don't affect too many packages.  Can you give us a list of new
> symbols in 2.39, to understand how significant this is?  Because there's a
> tension here between wanting packages to pick up the new interfaces, and
> wanting unrelated uploads of packages to not get stuck behind glibc in
> -proposed if the migration takes a long time.

I've attached the list. It is entirely composed of brand new symbols
rather than redefinition of existing APIs. The bulk of the symbols are
implementations of the <stdbit.h> header, which feels like the kind of
things that configure scripts check for and conditionally enable. That
is purely speculation on my part though.

> > * The newer glibc would be tested for less time, although presumably
> >   that's somewhat offset by it taking less time to reach the release
> >   pocket from -proposed.
>
> > WDYT?
>
> Thanks,
> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                   https://www.debian.org/
> slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.39_symbols
Type: application/octet-stream
Size: 2576 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20240130/f04c171a/attachment.obj>