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

[Panu Matilainen]

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.
> 
> Hi Panu,
> 
> With all due respect for your rpm.org maintainership, this hasty decision
> is very disappointing to say the least, both from organizational and
> technical points of view.
> 
> Silent reversion of contributed patches is definitely not the right way
> to attract young talented contributors to the project, just the otherwise.

Oops. It never was intended to be a silent reverse, I've simply 
forgotten to post about it. For that, apologies.

> If one has some issues with the patch that was submitted to this mailing
> list and reviewed here, the very least that's expected from an experienced
> and polite maintainer like you is to bring these issues back to this
> mailing list.
> 
> Please prove me wrong, but there was no urgency in reverting this commit
> without prior discussion the way you did.  If you brought the issue here,
> you'd promptly got an answer that the patch is correct and those
> thirty-something testcases have been broken because of test suite
> deficiencies.

In fact it was a rather urgent situation, otherwise I would've just 
brought it up here as usual. We needed to get rpm 4.14 alpha out and 
into Fedora in order to make it at all into F27 and there was no time 
for me to analyze whether 32bit architectures are really broken or if 
it's just the testsuite acting up.

That was last Thursday evening, babysitting rebuilds all the way to 
midnight. In the next morning, I had a pool of dog vomit waiting on my 
bedroom doorstep, piles of dog poop all over the living room, and what 
turned out to be a bug in rpm 4.13 threatening 4.14 to be reverted from 
F27 waiting in my inbox. And while assessing the issue, the other dog 
peed on my office carpet. The rest of tha day was a bit less action 
packed but come weekend, I can tell you it was one of those days you 
really want to just forget. Seems I forgot a bit too much, and again, 
apologies for that.

> 
> Indeed, how could you expect them not to break if the tool you use for
> testing - fakechroot - is simply not aware of LFS-capable fts in libc?
> 
> Adding fts64* support to fakechroot isn't rocket science.
> In fact, we have a patch in testing already.

Good to know and thanks for looking into it. We can then revisit the 
reverted patch later when the patch is fakechroot upstream. 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.

Maybe there simply is no other way to test it, but if there is I'd 
really prefer something less magic.

	- Panu -