> On 12 Nov 2022, at 00:53, Paul Eggert <eggert@xxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: Message signed with OpenPGP
