LFS status, and enabling it opportunistically on next SONAME bump

[Guillem Jover <guillem@debian.org>]

Hi!

Our Large File Support on some 32-bit architectures is a bit poor, and
this has been going on for a while now:

  <https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html>
  (Although this includes some false-positives as reported in #787853.)

In addition, the problem is actually worse than it seems, because even
programs that might not need nor usually have to read and handle large
files, might still fail, if they have to operate on files with large
metadata values, like inode numbers for example. A simple stat(2) on
a file might fail on a filesystem with large inode numbers, even if
the file is otherwise not large.

  (I've filed #792167 to clarify the above in the lintian tag description.)

If you've got one such package please consider enabling LFS, and if you
maintain a shared library that might need to bump its SONAME soon, for
example due to the gcc-5 transition, please use the opportunity to also
try to enable LFS at the same time. Shared libraries might not break the
ABI when enabling LFS, but doing so when bumping the SONAME means even
if they would break the ABI, it will be fine.

This still will not guarantee that LFS works, as an underlying shared
library might still not have LFS enabled, or any of the other problems
listed in the lintian tag might remain, but it's better than nothing
I guess.

Thanks,
Guillem