Re: Bug: tests/fsync.c: don't check for fsync failure on invalid fd

[Paul Eggert]

On 03/14/13 10:45, Phillip Susi wrote:
> Just because it checks for it does not mean that it depends on it.
> The question is does it break when run with eatmydata?  Does it break
> when built with eatmydata?
> 
> A cursory check of the source code indicates that it does not

It should be OK to *build* MIT Kerberos with
eatmydata, but any application that uses MIT Kerberos
could be iffy when *run* with eatmydata, for reasons
other than data loss.  I'm not confident of any analysis
of this issue if the analysis is based on cursory checks.

> Packages generally do ( and should ) expect the entire test suite to pass.

I don't expect that.  I regularly run test suites that don't pass,
when they're running on platforms that have bugs.  Solaris, for
example, doesn't pass the coreutils test suite right now.  It's OK:
eventually Solaris will fix its bugs.  Or maybe it won't, and that's
OK too.  The tests Solaris is failing are corner cases that aren't that
big a deal for ordinary users.

For the packages you build, you can either change eatmydata
(which should make it slightly more reliable without hurting
performance significantly) or change your build procedures to
skip or ignore the tests that eatmydata breaks.  Either of
these are easy things to do, and are a normal part of software
engineering practice.