The lustre-tests RPM is intended to be installed on the client, and is intended to be able to install on as many different systems as possible.
It shouldn't necessarily require ldiskfsprogs, since this is only needed on the server. If there are specific tests that require e2fsprogs commands, they should typically be using "do_facet" or similar to run on the server. Hmm, I guess sanity.sh test_37* does use a small loopback filesystems for testing block device and loopback files, but I wonder if these should use "skip_env" if mke2fs is not installed?
Similarly, pdsh is optional since it is possible to configure $PDSH to point to other tools that can do remote operations (such as SSH). It is also possible to run "client only" tests that do not have any remote access, and many subtests are skipped if remote server access is not possible (either because of no pdsh, or because the tester does not want to allow access to the server without a password). That said, I don't think tests are run in this more on a regular basis.
Perl usage was removed from master (in 2.2 commit 26bb579a) for the one test that I'm aware of that used it directly (sanityn.sh test_3), and I'm not aware of other tests that currently depend on it. There are a few scripts that do use perl (e.g. checkstack.pl, rename.pl, leak_finder.pl), but they do not run as part of any normal test. Since perl is pretty much ubiquitous, I don't think this is critical either way.
There is a check in test_102a() for setfattr that avoids running tests that depend on them if they are not installed. It looks like this check is missing from some of the other test_102* subtests. Similarly, test_103() checks for getfacl before running the ACL tests.
In general, I agree that we want to make the tests as easy to install and run as possible, but I also want to avoid dragging in too many dependencies that may make it harder to install the RPM and run the tests in the first place.
"Pick your favorite poison."
Perhaps jigger something to trap on "command not found" errors?
Our testing guys were sufficiently frustrated that the bug report
that landed on my desk was marked, "blocker". Perhaps an exaggeration 
.
The automake way is to wrap all dubious tools inside a script wrapper
named "missing". If the "missing" script finds the tool, it exec-s it.
Something similar? Surely not today though. Maybe part of the testing
rework.
Meanwhile, folks here thought it really, really important to add these
dependencies to the lustre-tests rpm. And we (you and I) agree that
there are trade-offs. Can we (Whamcloud and Xyratex) agree on where
to draw the line? Cheers - Bruce
LU-1199 is also looking at fixing up the spec file.
It is currently on hold and the residue of this patch should have no effect on that project anyway.
Actually, that project does not explicitly state that comprehensibility is a goal. Comprehensibility
is as important in a spec file as it is in a source file, so it needs to be a goal.
Bruce is there a follow up to the first patch? Any new patch should be based on Master.
Xyratex-bug-id: MRP-488
Without an update I will close this LU at the end of the month.
Please reopen if you decide to peruse this in the future.
I notice that http://review.whamcloud.com/#change,2851 was pushed into gerrit. Is this directly related to this original ticket or would it be more appropriate to track this under a new ticket?
That change was strictly cleanup. Shell scripting going past column 168 gets me cross-eyed.
Our testing folks are not still complaining, so I'm not being prodded to push another patch.
Stillandall, it is inconvenient for a tester to run a test and wind up seeing some obscure
failure instead of a clear message: you have not installed the "foo" package, so you
cannot run this test. A good model for handling the issue is the "missing" wrapper script.
Either that, or put in appropriate dependencies so that testing packages pull in what's needed.
There is a new patch.