Hi Paul,
In yesterday's changes, you added to the Gnulib documentation, section
"Avoiding the year 2038 problem", wording that
* explicitly recommends the ‘year2038-required’ module,
which does AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]):
"The Gnulib module ‘year2038-required’ is recommended for any package
that might be used after the year 2038 on 32-bit platforms."
* presents the ‘year2038-required’ module as the first and the ‘year2038’
module (which does AC_REQUIRE([AC_SYS_YEAR2038])) only as the secondary
option.
I strongly object to this recommendation and presentation.
The reason is that we have three personas:
- The package maintainer who edits configure.ac.
- The distro people who create distros comprised of many packages,
passing appropriate options to 'configure'.
- The user / sysadmin who installs packages on their systems from source,
passing appropriate options to 'configure' as well.
If the package maintainer adds an AC_SYS_YEAR2038_REQUIRED invocation to
his package's configure script, or equivalently, if he pulls in the
'year2038-required' module, he is *taking freedom away* from *both* the
distro people and the users/sysadmins.
It is simply the wrong person's decision if the package maintainer
uses the AC_SYS_YEAR2038_REQUIRED macro.
In detail:
When AC_SYS_YEAR2038_REQUIRED is used, the package can no longer be
installed on the following 32-bit platforms/ABIs:
- Linux with glibc < 2.34 on x86, arm, mips (32-bit or n32 ABI), powerpc,
sparc, s390, hppa, m68k, sh, csky, microblaze, nios2,
- Linux/riscv32,
- Mac OS X on x86 and powerpc,
- GNU/Hurd/x86,
- GNU/kFreeBSD/x86,
- FreeBSD/x86,
- MidnightBSD/x86,
- AIX/powerpc,
- Solaris 10 and 11 on x86 and sparc,
- Cygwin/x86,
- Haiku/x86.
Regarding the distro people:
The outcome of a discussion, about a month or two ago, was AFAIU that
Linux/x86 and Linux/arm distros have a choice between
(a) enabling 64-bit time_t for all packages, thus breaking ABI
compatibility once and becoming year 2038 saft, or
(b) staying with the 32-bit time_t, and announcing that their
distro will stop working in 2038.
An incremental or partial move to 64-bit time_t would be too expensive,
did the distro people say.
Now, if a package maintainer adds AC_SYS_YEAR2038_REQUIRED to their
configure.ac, they are telling the distros of type (b) "you cannot use
new releases of my package any more".
This is discriminatory and without justification, since the maintainers
of a type (b) distro already know that they have to limit the lifetime
expectations of their distro.
Regarding the users/sysadmins:
It is their decision to know until when they want to use their hardware,
and which ABI they want to use for the binaries that they install on
this hardware.
Now, if a package maintainer adds AC_SYS_YEAR2038_REQUIRED to their
configure.ac, they are telling the users "you cannot install releases
of my package any more" or "I force you to install 64-bit binaries
instead of 32-bit binaries".
It is just not appropriate for the package maintainer to push such a
decision onto the user.
I would therefore propose that the module 'year2038-required' gets
removed from Gnulib, as I cannot see any positive uses of it.
If that is not possible, then at least:
1) The Gnulib documentation should present 'year2038' first, and
'year2038-required' as a rarely needed alternative,
2) The Gnulib documentation should not recommend 'year2038-required'.
Note: In constrast, there is nothing wrong with the Autoconf documentation.
It presents the AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED macros
without favouring one or the other.