On 2022-11-12 06:16, Zack Weinberg wrote:
I am going to go ahead and do this if nobody raises a concrete objection within the next 24 hours.
I object to a simple reversion, as this will cause problems downstream with Gnulib-using applications, several of which have already been released assuming the current Autoconf git will go into the next release, and which will stop working if built from Git with an Autoconf 2.72 where the AC_SYS_LARGEFILE changes have been reverted. Current Gnulib assumes that AC_SYS_LARGEFILE will behave in Autoconf 2.72 like what's in Git now. If we change AC_SYS_LARGFILE back, we will need to change Gnulib too, and update downstream apps accordingly.
Instead, I suggest a partial reversion, in which AC_SYS_LARGEFILE goes back to its previous meaning by default, but there is a well-documented way to get the current in-Git meaning, a way that Gnulib can recognize and use. For example, you'd get the new meaning if you configure with --enable-year2038, or if configure.ac uses a new macro AC_SYS_LARGER_FILE that supersedes AC_SYS_LARGEFILE. This will also require some Gnulib changes, but they'll be more reliable and stable than whipsaw changes required by reverting then whatever future changes Autoconf makes.
This proposal would resolve the backward-compatibility concerns for people who want to delay worrying about year-2038 issues, while also resolving the compatibility concerns of Gnulib. It would also provide a better-documented way for distros that want to switch to 64-bit time_t.
Of course this sort of thing cannot be written and tested in an hour. But reverting is not that simple either, and would be a less efficient use of everybody's time.
