XPost: linux.debian.devel.release
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)