Hi Simon, On Mon, Feb 26, 2024 at 11:40:56AM +0000, Simon McVittie wrote: > > glib2.0 # already in experimental
> The upstream version in experimental is unsuitable for unstable, but it's > "the same shape" as the version in unstable in all the places that matter, > and we ack'd the earlier NMU to experimental already, so I'm confident > that similar changes will apply cleanly to the version in unstable. The > GNOME team can probably handle this one when the time comes, if that > would help (I know your Canonical colleague Jeremy Bícha was asking to > let the GNOME team do coordinated team-uploads rather than NMUs, I'm not > sure what the resolution of that was). Yes, this is on the list to flag that it is a package for which we do not have a guarantee of dumat coverage in experimental prior to uploading to unstable, and thus we might hit usrmerge problems for the first time in unstable. In this particular case the t64 NMU sat in experimental for 2 weeks (31Jan-13Feb) before being replaced by a maintainer upload. So I trust that Helmut would have screamed at me if glib2.0 had gone pear-shaped. But that is a finer level of investigation than we have the capacity for at this stage for each of these 50+ packages. > Also, if it's valid to apply this reasoning: > - libhigh0 depends on liblow0 > - liblow0 will transition to liblow0t64 > - libhigh0 does not really need to change its name because we know that the > version built against liblow0 is the old ABI, the version built against > liblow0t64 is the new ABI, and they cannot be co-installable > then we can cross all of the GLib-based packages off the list > immediately, and handle them by transitioning glib2.0 from libglib2.0-0 > to libglib2.0-0t64. That covers at least these: > > evolution # no sane ABI info, but maintainer handling via e-d-s > > gimp # already in experimental > > gtk+2.0 # false positive > > gtk+3.0 # false positive > > libvirt-glib # ftbfs > > mutter # already in experimental > > telepathy-farstream # known ftbfs > ... and similar logic could be applied to in the Qt ecosystem, with Qt > as the low-level package. Does that help to reduce the numbers? Special-casing these stacks because they don't "need" to be renamed is, on our side, more work and more prone to mistakes than if we just include them in the mass NMU. *Not* renaming is not meaningfully better as a user experience than renaming, so I don't think it's valuable from the perspective of the overall transition to carve out these exceptions. If maintainers are confident that the renames are unnecessary and want to remove the 'pending' tag from the bug reports to exclude them, or want to revert the renames after upload, that's their choice. The only caveat I would raise is that on the Ubuntu side, we're working to a very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this Thursday, and while I think we're going to vary our Debian Import Freeze in order to get the time_t transition through, we aren't going to vary it by much. So maintainer name reverts in unstable that happen after this are not guaranteed to be picked up, and whatever package names we have on the Ubuntu side are going to be locked in for a 10-year LTS cycle. So I think any maintainer who's concerned about dependency compatibility with third-party debs should bear this in mind. -- 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
