Uwe Kleine-König <uklei...@debian.org> writes: > to help making package maintainers aware of the Y2038 problem I > implemented a lintian check that triggers if a symbol from glibc is used > that uses a 32bit time_t type.
> The code is available in a MR on the lintian packaging repository at > https://salsa.debian.org/lintian/lintian/-/merge_requests/463 I have no objections to adding this as an experimental tag. The detection component to determine the size of the problem is certainly useful. However, more generally, do we know yet how Debian intends to handle this transition? Changing to 64-bit time_t will change the ABI of shared libraries and thus is not a safe change to make without an SONAME transition unless we're going to do something architecture-wide, such as introducing a new version of the i386 architecture where everything is built with 64-bit time_t. I know there's a caution in there already about this, but I'm concerned about maintainers acting on this tag by blindly adding the Autoconf flags or macros to switch to 64-bit time_t and thus creating numerous uncoordinated shared library transitions, possibly without knowing they need to change the SONAME. And it's not clear to me that we want to do the migration by changing the SONAME of every shared library in Debian that uses time_t has part of its public API (which is a lot of them). I know of at least one package (and I am certain that there will be more) where this change will also change on-disk data formats in a way that is not backward-compatible, which is even less safe. The current caution should probably be stronger: it's only safe to do this transition for leaf packages that do not call any shared library functions with time_t parameters and that do not use time_t in any binary data structures stored on disk (possibly including caches, depending on the situation). In other situations, this is something that's going to require some distribution-wide coordination that I don't think we've started yet. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
