Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On 10/04/2023 14:40, Bruno Haible wrote:
> 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.

Yes I'm a bit confused with the new restrictions myself.
A build on Solaris 10 on sparc for example now fails.
I was able to get a build to complete though by passing this to configure:

   ac_year2038_required=no

I'm confused also about the auto detection / rejection modes for this.
IIUC, previously a build would fail only if `touch -t` could create 64 bit times,
while the build was setup for 32 bit time_t. But now the build fails
irrespective of what touch supports. For completeness touch on this platform
does not support 64 bit times.

   > touch -t 203901010101 file.t
   touch: bad time specification

   > touch -t 203701010101 file.t

   > src/touch -t 203901010101 file.t
   touch: invalid date format '203901010101'

   > src/touch -t 203701010101 file.t

cheers,
Pádraig