[Rpm-maint] [PATCH] Revert "Only build bundled fts if system has a bad version that doesn't handle LFS"

Dmitry V. Levin ldv at altlinux.org
Thu Aug 17 20:28:03 UTC 2017


On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote:
> On 08/16/2017 11:51 PM, Dmitry V. Levin wrote:
> > On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen wrote:
> >> The subtle test is too subtle for its own good, this patch breaks
> >> thirty six testcases on 32bit architectures.
> >>
> >> This reverts commit 1eadabe4453ef32eb6c3bc837094e1ca998affcc.
[leaving non-technical part aside for a while]
> But as the 
> revert commit message says, the test is way too subtle for my liking, I 
> never liked it at all because of that. In retrospective, that distrust 
> combined with the clock-is-ticking situation ... I don't think I  ever 
> actually thought to suspect fakechroot in this case.

Sorry but your distrust of AC_CHECK_HEADERS([fts.h]) looks rather irrational.
What kind of doubts do you have wrt this very basic test?

Do you have any doubts about AC_CHECK_HEADERS documented behaviour, e.g.
that it uses the compiler to test header usability, and it is affected
by the arrangements made by AC_SYS_LARGEFILE?

Even the memorable 8-year-old change of AC_CHECK_HEADERS behaviour
described in [1] shouldn't affect this case because glibc's fts.h used
to issue an "#error" in case of _FILE_OFFSET_BITS==64 thus breaking
the preprocessor test, too.

There are plenty of AC_CHECK_HEADERS invocations in configure.ac -
do they also look doubtful to you?

[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/html_node/Present-But-Cannot-Be-Compiled.html


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170817/25702e75/attachment-0001.asc>


More information about the Rpm-maint mailing list