Wookey <wookey@xxxxxxxxxxxx> writes: > Now, I'm not yet sure if just having autoconf 2.72 will actually break > things. AIUI, these changes only apply where LFS > (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that > is not the default on 32bit arches, maybe this is OK. But probably quite > a lot of packages already enable LFS so they are suddenly going to get a > new ABI if they expose timet anywhere? > https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows > 163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is > used by a lot of packages (as you might expect - this transition has > been going on for many years). And just having that macro in > configure.(in|ac) will turn 64-bit timet on if you autoreconf with > 2.72. Right? If indeed pre-existing use of AC_SYS_LARGEFILES would suddenly enable 64-bit time_t on autoreconf, I can name two packages just off the top of my head that this change to Autoconf will immediately break if their Debian packages are rebuilt with a newer version of Autoconf, creating severe bugs. libremctl will have its ABI changed without any coordination or versioning (which I will be doing, moving forward, but have not started tackling yet in part because I was waiting to see what the plan would be and whether there will be some coordinated change to SONAMEs, a new architecture, or what). And INN, which admittedly is a disaster about things like this for lots of historical reasons, will have its *on-disk file format* changed without notice in a way that will cause serious failure and possibly data corruption on upgrades. This is just wildly backward-incompatible and seems like an awful idea. If we're going to throw a big switch and rebuild everything, it needs to be done at a distro-wide level. I believe the only safe thing for Autoconf to do is to provide an opt-in facility, similar to what was done for AC_SYS_LARGEFILE, and then leave deciding whether to opt in to higher-level machinery. > However my limited understanding as of right now says that autoconf 2.72 > tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72 can't be > used in debian yet. So I currently favour not tying them together in > this release. That's also my understanding from the thread so far, although I'm not sure that I'm following all of the subtleties. > People have been using AC_SYS_LARGEFILE without 64bit time_t for many > years now so it's not yet clear to me why that cannot continue. And these are conceptually not at all the same thing. I saw Paul's explanation for why he views them as fundamentally the same because of their effect on system calls like stat, but I certainly don't think of them that way and I am quite dubious many other people will either. The set of things that I have to check to ensure that time_t is handled correctly is totally different than the set of things I thought about when enabling AC_SYS_LARGEFILE many years in the past. I recognize that there will be overlap once file timestamps are past 2038 and that will happen sooner than anyone plans for, but it's still true that this has *not* happened right now and this therefore is not currently creating many bugs, whereas this switch in this way will create many, very serious bugs immediately. -- Russ Allbery (eagle@xxxxxxxxx) <https://www.eyrie.org/~eagle/>
