For mipsel, we have one more thing to do:
- NaN2008 vs NaN legacy
So I'd prefer rebootstrap (only for mipsel).
And In fact we did it: https://repo.oss.cipunited.com/debian/
Russ Allbery <r...@debian.org> 于2023年5月17日周三 12:31写道：
>
> Steve Langasek <vor...@debian.org> writes:
>
> > * Largely via NMU, add a “t64” suffix to the name of runtime library
> > packages whose ABI changes on rebuild with the above flags. If an
> > affected library already has a different suffix (c102, c2, ldbl, g…), drop
> > it at this time.
>
> This is possibly me being too fiddly (and also I'm not 100% sure that I'll
> get to this in time), but ideally I'd like to do an upstream SONAME
> transition for one of my shared libraries (and probably will go ahead and
> change it for i386 as well, since I'm dubious of the need to run old
> binaries with new libraries in this specific case).
>
> What's the best way for me to do that such that I won't interfere with the
> more automated general transition? Will you somehow automatically detect
> packages that have already been transitioned? Or should I wait until the
> package has been automatically transitioned and *then* do an upstream
> transition?
>
> > Your thoughts?
>
> The one additional wrinkle is that there are packages that, due to
> historical error or unfortunate design choices, have on-disk data files
> that also encode the width of time_t. (I know of inn2, which is partly my
> fault, but presumably there are more.) Rebuilding that package with the
> 64-bit time_t flags would essentially introduce an RC bug (data loss)
> because it will treat its existing data files as corrupt. Do you have any
> idea how to deal with this case?
>
> (The LFS transition was kind of a mess and essentially required users to
> do manual data migration. This time around, maybe we'll manage to write a
> conversion program in time.)
>
Since there may be some unknown problems, we cannot tell our user that
they can upgrade smoothly, no matter rebootstrap or rebuilding some packages.
So I guess, rebootstrap may be a better choice, at least for users to
understand what we did.
> --
> Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>
--
YunQiang Su
