Gabor Szabo wrote:
If a real world user can also have similar setup using NFS, then this is a 
legitimate setup, isn't it?
I can hardly imagine a real system with /tmp being on NFS, but yes, it's possible, and I don't argue with this. My point is, once problem is found, do authors need more reports with the same issue if this issue has nothing to do with the module functionality? I think no. Problem appears when I call Test::Script::script_compiles, it calls IPC::Run3, which in turn calls File::Temp, and "unlink0" function cannot guarantee actual removal of file on NFS. "script_compiles" is a very basic sanity check and if it fails, then something is absolutely wrong. Yes, most likely, Test::Script should have a test for this and refuse to install, but I don't see how *I* can do something about it.
Isn't this exactly the same situation as Windows vs Linux, where
Windows might not support all
the features Linux does?
Not really. If module fails on Windows, it fails every time "make test" is 
executed on Windows machine.
If module cannot be compiled on this machine (because of missing library or something), it will get UNKNOWN grade. It's not the same situation. I'm fine with getting UNKNOWN. I'm not fine with getting FAIL when it's a problem with testing infrastructure that my modules are not using during real-world tasks.
Are those only test failures, or is the module (partially) broken on a
system using NFS?
Which module? If you're talking about my module, it's not.
File::Temp, which is used by *test* harness, is somewhat broken.
That's my point, when problem is found and located, then affected smoker should 
be stopped to prevent entropy increase.
If the module does not fully work over NFS then shouldn't it recognize
the situation
and disallow those features?
Well, you cannot actually know is it NFS or not on when rusing library 
interfaces without hacks. And I don't like hacks.
If only the tests fail on NFS, shouldn't those be skipped?
The only way I see it's skipped is to skip when $ENV{'HOME'} =~ m!^/home/njh! but it's extremely counter-productive. I'd rather live with false positives :)

--
S.T.

Reply via email to