> On 12 Nov 2022, at 00:53, Paul Eggert <egg...@cs.ucla.edu> wrote: > > On 2022-11-11 15:25, Sam James wrote: >> That's not a judgement on whether the changes will ultimately remain in >> autoconf, I'm just >> hesitant to allow a discussion I've kicked off to derail something that we >> were planning >> on doing anyway. >> What do you think? > > I'm hesitant to do that partly because the changes to _TIME_BITS are already > released in multiple packages and need to be dealt with, regardless of > whether they're backed out of Autoconf. This is because they've been in > Gnulib since July and several packages based on these Gnulib changes have > been released since then. Current Gnulib assumes these changes will appear in > the next Autoconf release; if that's not true, we'll need to upgrade Gnulib > and in the meantime the other packages released since July would still have > the changes whatever we do with Gnulib and/or Autoconf. > > Since distros need to deal with the issue anyway, regardless of what Autoconf > and/or Gnulib does, I don't see why backing the changes out of Autoconf will > help all that much. > > It should pretty easy for a distro to say "hold on, I don't want 64-bit > time_t yet" without changing either Autoconf or Gnulib so if you want to go > that route please feel free to do so.
The fact it's already shipped in gnulib & that the "real problem" is in glibc IMO means that I don't feel strongly about reverting it. You're right that distros have the toggle so as long as we mention this prominently enough in NEWS, I don't have a strong objection to master being released as-is.
signature.asc
Description: Message signed with OpenPGP