Hello Russ,
On 4/20/23 19:40, Russ Allbery wrote:
Uwe Kleine-König 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'm not aware of a decision how this should be handled. The lintian tag
is a step to measure the actual problem by identifying the packages that
need some love. Also independent of a global effort I expect that a big
number of leaf packages can simply be converted. Further it probably
helps to spread awareness and maintainers might tackle the update if a
soname bump has to be done for other reasons anyhow.
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 wonder if there is a list already of such libs.
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.
I expanded the tag's description to point out that converting to time64
probably needs some care. If you have a concrete proposal to improve it
further, I'm open for feedback.
Best regards
Uwe
