[Pkg-rust-maintainers] Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Simon McVittie]

On Tue, 12 Mar 2024 at 23:13:30 -0500, Steven Robbins wrote:
> I checked the build logs for cargo and noticed that most architectures have 
> been built on the buildds.  All release arches except armel & armhf.  How is 
> it that these two have build dep installability problems but others do not?

Those two are the only release architectures where the 64-bit time_t
transition has caused an ABI break:

1. amd64, arm64, mips64el, ppc64el, riscv64, s390x are all 64-bit, so they
   already had 64-bit time_t
  - non-release architectures in the same category:
    alpha hurd-amd64 ia64 loong64 ppc64 sparc64

2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
   because its major purpose this decade is running legacy 32-bit binaries,
   a purpose that would no longer be possible if it broke ABI
   - non-release architectures in the same category: hurd-i386 (I think)

3. There is currently no release architecture that is 32-bit but already had
   a 64-bit time_t prior to 2024
   - non-release architectures in this category: x32

4. armel, armhf are the two remaining 32-bit release architectures after
   excluding all of the above
   - non-release architectures in the same category:
     hppa m68k powerpc sh4

I hope that helps to categorise the architectures that do/don't have a
problem here.

For architectures in categories 1, 2 and 3 above, libfoo0 is still renamed
to libfoo0t64, but libfoo0t64 Provides: libfoo0, making it significantly
easier to satisfy build-dependencies. The last category is the only one
where there has genuinely been a compatibility break and therefore this
Provides would be wrong, so it is also the category where some packages
need re-bootstrapping.

    smcv