Just noticed this bug. The discussion in this bug makes me worry that people do not fully understand the implications of enabling 64-bit time and large file system support respectively.
It's great to see people starting to care about this issue and fix things (it's overdue), but I'm just chiming in to point out that some care is needed before turning these options on. Debian is in the process of developing a plan for this transition, but has not got very far yet. I have just started a wiki page to cover the issues (and tagged this bug): https://wiki.debian.org/ReleaseGoals/64bit-time https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-de...@lists.debian.org;tag=time64 If tar is currently building without LFS enabled, I'd suggest maybe turning that on, checking things, and uploading before also turning on 64bit time_t. They can be done separately (in that order only). Both have the potential to change file formats and ABIs (although tar is a program not a library so no ABI is exposed). Hopefully upstream has looked at all this carefully and is reasonably sure nothing important will break? For LFS enablement you should be aware that LARGEFILE_SOURCE and FILE_OFFSET_BITS=64 do different things. The former enables both 32 and 64-bit interfaces, the latter chooses the 64-bit interface only. You probably only want the latter. (depending how these are used in the codebase, it may not make any practical difference) For 64-bit time_t enablement you might want to wait for the dpkg standard debian mechanism to appear and use that: https://bugs.debian.org/1030159 You certainly want to be sure that things tar depends on (and expose ABIs or file formats that change) have switched first. Now tar is close to the bottom of the stack so this may well be fine, but it's linked against libacl, libselinux, libc and libpcre2, so we should check those. I am in the process of running abi-compliance-checker over all debian libraries to get a list of ones that expose an ABI change from either enabling LFS or 64bit-time_t. tests so far say: libacl1 is safe (no change) libselinux is unknown (did not build) libpcre2 is unknown (did not build) (I'll take a look at those now as they are pretty fundamental) If you choose to use gnulib, note that it turns 64-bit time on by default if detected in glibc, unless you set a macro to explicitly keep 32-bit time. So in summary, tar is a good candidate for enabling LFS and time64 early but some checks should be done first, unless it is known that there are no external interface changes other than to glibc. I hope that is helpful. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: PGP signature
