I support transitioning to 64-bit time_t. Thank you for taking this on!
Gentoo has a similar migration: https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migrationThey mention, "We likely have to complete Modern C porting first to remove any instances of -Wimplicit-function-declaration otherwise the redirects in glibc for e.g. time->time64 won't actually work." That links to:
https://inbox.sourceware.org/libc-alpha/874js2iqlg....@oldenburg.str.redhat.com/Has that issue been considered here? (I can't speak intelligently on it at this time. I just want to make sure it's on your radar.)
On 2023-05-16 23:04, Steve Langasek wrote:
* For a small number of packages (~80) whose ABI is not sensitive to time_t but IS sensitive to LFS, along with their reverse-dependencies, filter out the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. Maintainers may choose to introduce an ABI transition for LFS, but as this is not required for time_t, we should not force it as part of*this* transition.
My gut feeling is that this is a mistake. I think Debian should just bite the bullet and force the LFS transition too.
First off, it seems that would simplify the planning, as you don't need to determine "[i]f there is a package that depends on both a time_t-sensitive library and an LFS-sensitive but time_t-insensitive library". Furthermore, that state could change in the future. In other words, someone could upload a new package that meets that criteria, which would then force a library to transition at that point. But would that requirement to transition get noticed, or would we end up with subtle breakage?
Also, how many separate times would someone have to do those LFS transitions vs just doing it all now in one shot?
I know it's not my place to volunteer you/others to do more work. But I worry about doing something half-way rather than just pulling the thread now. Doubly so since it's a relatively small set of additional packages compared to the size of the rest of the transition already being planned.
Back to time_t... Application-level workarounds can complicate things...Upstream NTPsec and gpsd had some conversations about the optional 64-bit time_t. They (and other projects) can have a shared-memory connection where the size and layout of the struct varies depending on sizeof(time_t). The glibc optional 64-bit time_t makes that complicated, as it's possible for the two applications to be mismatched.
The conclusion we came to (which has been implemented in gpsd, but has not yet been implemented in NTPsec) is to split the time_t and put the high bits into a spot that was reserved/padding, but only in the case where we have optional 64-bit time_t and 32-bit ints. This provides compatibility between modified and unmodified applications until 2038, and modified applications work together thereafter. If you're curious, the relevant subthread is:
https://www.mail-archive.com/devel@ntpsec.org/msg09645.htmlWith the Debian transition, we could end up with a mismatch where one side (gpsd) is sized with 32-bit fields and doing the split thing and the other (NTPsec) will be sized with 64-bit time_t, which is incompatible. Whether that happens is dependent on how exactly the applications implement the check to decide to do the split thing. I've raised that question on the gpsd bug:
https://gitlab.com/gpsd/gpsd/-/issues/152#note_1395291465There are certainly solutions to that. In no way am I suggesting that should block the transition. By all means, transition and we will sort things out.
-- Richard
OpenPGP_signature
Description: OpenPGP digital signature
