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

[Panu Matilainen]

On 08/17/2017 11:28 PM, Dmitry V. Levin wrote:
> 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?

Meh.

"Any technology, no matter how primitive, is magic to those who don't 
understand it."

The "earlier configure.ac foo hidden side-effects cause this to do 
something else" that somehow ends up being completely counter-intuitive 
and magic to me. I'm still deep in the superstition phase when in comes 
to autoconf ;)

	- Panu -