On Sun, 05 Jan 2025 at 23:58:40 +0100, Chris Hofstaedtler wrote:
> as we've seen in the time_t-64 transition, programs that interpose
> library calls like this are extremely hard to get right and very
> brittle.
>
> I would strongly suggest to not put new load-bearing stuff on top of
> such a program, especially when the rest of Debian is trying to get
> rid of fakeroot.
Yes, this; but unfortunately...
> Maybe you can consider using a time namespace (unshare -T) and
> change the system date/time in that namespace.
... this isn't a feature that time namespaces offer. Unless the
documentation in time_namespaces(7) is outdated, time namespaces currently
only namespace CLOCK_MONOTONIC* and CLOCK_BOOTTIME*, not CLOCK_REALTIME;
but it's CLOCK_REALTIME (and related clocks like CLOCK_TAI) that represent
wall-clock time, so it's those clocks that you'd need to fake in order
to answer questions like "what would happen if we recompiled this package
5 years in the future?".
Simpler/higher-level functions like time() and gettimeofday() usually
use the same clock as CLOCK_REALTIME, except for functions like
g_get_monotonic_time() that specifically say they use a monotonic clock.
This also means that time namespaces are not (yet) a way to run legacy
binaries post-2038 by telling them an earlier date.
As far as I know, both of those use-cases require either LD_PRELOAD
interposing (brittle and error-prone) or a virtual machine with its clock
intentionally set incorrectly.
smcv
