Re: [Rpm-maint] [PATCH] Revert "Only build bundled fts if system has a bad version that doesn't handle LFS"
On Fri, Aug 18, 2017 at 08:22:23AM +0300, Panu Matilainen wrote: > 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. You hardly can call them hidden because they are clearly documented, e.g. https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/html_node/System-Services.html#index-AC_005fSYS_005fLARGEFILE-1102 says "Define _FILE_OFFSET_BITS and _LARGE_FILES if necessary". > I'm still deep in the superstition phase when in comes to autoconf ;) You know, this can be fixed, too. ;) -- ldv signature.asc Description: PGP signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Revert "Only build bundled fts if system has a bad version that doesn't handle LFS"
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 - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Revert "Only build bundled fts if system has a bad version that doesn't handle LFS"
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 signature.asc Description: PGP signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
