On Wed, Feb 15, 2023 at 05:08:40PM +0000, Wookey wrote:
> On 2023-02-04 21:42 -0800, Steve Langasek wrote:
> > On Thu, Oct 20, 2022 at 09:42:58PM -0700, Steve Langasek wrote:
> > > This is good. One thing that I think has been missing from the discussion
> > > about armhf rebootstrap is the fact that we do have experience in Debian
> > > doing cross-cutting ABI transitions without having to change an
> > > architecture name. We've done this at least three times in Debian history:
> > > the libc5->libc6 transition ('g' suffix - which still remains today in
> > > libpam0g!), the GCC 4.0 C++ ABI transition ('c2' suffix), and the 'long
> > > double' transition ('ldbl' suffix, and an example of doing this for an ABI
> > > transition that didn't affect all architectures).
> I feel like I should already know this, but after a bit of thought,
> and reading the transitions wiki page:
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions I do not
> understand how the suffixes are used in these transitions.
> That wiki page does not appear to mention adding suffixes to package
> names. It appears to only document the process where the version is
> just bumped, everything involved is rebuilt in experimental and then
> re-uploaded to unstable once we are ready to make the change.
> I presume that the suffix is used for transitions involving a large
> number of packages, in order to keep both the old-ABI and new-ABI
> version of the packages around in parallel (and conflicting with each
> other?) for a while which is necessary for larger transitions because
> doing it all in one go would take too long, or get entangled with
> uploads from the unware that might cause breakage, or something?
When we have an ABI change in the distro that affects shared libraries, but
is not the result of sourceful changes to the upstream source, we don't want
to change the soname of the library; that's upstream's domain.
But we do need at the packaging level to distinguish between two packages of
the library that provide different ABIs, so that packages depending on one
ABI don't incorrectly get the package with the other ABI, resulting in
broken runtime behavior.
When we transition, the un-annotated package will remain present in older
releases, but will be entirely superseded in unstable by the package
providing the new ABI.
BTW, I'll suggest "t64" as the library name suffix here.
> Just rebuilding and not renaming sounds like a much smoother process,
> because as soon as we rename then there is a load of renaming in
> reverse dependencies too, and there is presumably a set of rules about
> when conflicts are added and other details that need to be got right.
No, that breaks partial upgrades and makes a right mess of unstable *and* of
upgrades between stable releases. "Just rebuilding and not renaming" is the
"rebootstrap" approach which I am hoping to avoid.
--
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@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature