Re: [PATCH] Deprecate 32-bit off_t support

[Guillem Jover <guillem at debian dot org>]

Hi!

On Fri, 2019-01-04 at 13:39:59 +0100, Florian Weimer wrote:
> diff --git a/NEWS b/NEWS
> index cc20102fda..2f601c6217 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -85,6 +85,15 @@ Deprecated and removed features, and other changes affecting compatibility:
>    as all functions that call vscanf, vfscanf, or vsscanf are annotated with
>    __attribute__ ((format (scanf, ...))).
>  
> +* A future release of glibc will use a 64-bit off_t type on all
> +  architectures (as currently available with -D_FILE_OFFSET_BITS=64 on
> +  32-bit architectures).  Building new applications with
> +  -D_FILE_OFFSET_BITS=32 will no longer be supported.  The off64_t type and
> +  the 64-bit function aliases (such as fstat64) will remain available under
> +  the appropriate feature test macros.  In preparation, libraries should
> +  stop using off_t in public header files, and use off64_t (or a fixed-width
> +  type such as int64_t or uint64_t) instead.
> +
>  Changes to build and runtime requirements:
>  
>  * Python 3.4 or later is required to build the GNU C Library.

While I'm fully behind further pushing to get software to switch to
build (and work) with LFS (that's the reason I proposed the below lintian
tag some time ago), it feels that something like the above might still be
a bit too aggressive? :/

For example in Debian that would probably imply not being able to
upgrade to such glibc until at least all shared libraries and packages
supporting and implementing plugins listed at

  <https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html>

have been transitioned (with either SONAME bumps, or package renames
with Breaks/Conflicts), or determined to not affect their ABI. Please
notice at the top, the comment about that page only having a truncated
view of the affected packages; in addition there might be other packages
not being currently detected.

Thanks,
Guillem