Chris Hofstaedtler wrote: > On Fri, Jun 27, 2025 at 01:14:07AM +0200, Guillem Jover wrote: >> I see no explicit mention of the time64 transition. I think this should >> be documented because the transition involved a no-SONAME-rename which >> means we broke the involved architectures ABI, where we protected the >> archive from that breakage via packaging metadata. But for locally >> built code, this can silently break it while those binaries do not fail >> to link. The exception (and its rationale) for i386 should also be >> mentioned. > > Agreed, but somebody needs to come up with the text. > > I don't know the rationales and what is actually noteworthy about > the transition.
First question: where does it go? If we think of it as a "new feature" of Y2038-safety, it ought to go in 2.2 or thereabouts; if we're putting the emphasis on the dangers then it belongs in 5.1 (perhaps immediately after the section on i386). There's material at https://wiki.debian.org/ReleaseGoals/64bit-time (including particularly the "Goal Description" and "Issues" sections), though that page could itself do with an overhaul to account for the fact that the transition is finished. Here's a first stab at it just to get the ball rolling: 2.x time64 ABI transition ~~~~~~~~~~~~~~~~~~~~~~~~~ All architectures other than `i386` now use a 64-bit `time_t` ABI, which can deal with dates beyond 2038. This transition required the 32-bit `armel` and `armhf` architectures to change the libraries involved without a change of soname ([[https://wiki.debian.org/ReleaseGoals/64bit-time|see wiki page for details]]), so third-party software handling dates on these systems will need to be recompiled to avoid breakage. The `i386` architecture did not participate in this transition, since its primary function is to support legacy software. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
