Steve Langasek wrote: > On Sat, Sep 24, 2011 at 03:49:11PM -0500, Jonathan Nieder wrote:
>> It also has a negative side-effect that Debian would no longer be doing >> its part to get > >> #define _LARGEFILE_SOURCE >> #define _FILE_OFFSET_BITS 64 > >> put directly in upstream's config.h when appropriate. > > In your estimation, when is it appropriate to do this? Basically always. Autoconf has an AC_SYS_LARGEFILE macro to do it. I actually had assumed most upstreams do it already. I don't see any reason that it wouldn't be the appropriate default on all platforms (and hence an upstream issue). [...] > Probably better to check for those calls that explicitly use off_t. Good point. [But open() without _FILE_OFFSET_BITS=64 fails with EOVERFLOW on large files.] [...] > We've had > an opt-in way of doing this for years: > > DEB_CFLAGS_MAINT_APPEND := $(shell getconf LFS_CFLAGS) > > And the uptake has been poor. It seems a bit disingenuous to say that. I at least was not aware that that command is something I should make a conscious choice to use or not to use for years. (Thanks for bringing $(getconf LFS_CFLAGS) to my attention, by the way.) Most programs I have worked on used _FILE_OFFSET_BITS=64 or used open64 et al explicitly already. I think making the percentage of the archive without large file support more well known and putting packages that lack it in the spotlight could have a lot of impact, and I would be happy to work on those packages I use that have trouble with large files. Thanks for the clarifications. Jonathan -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
