Hey Paul, Thanks for the quick response.
On Wed, Oct 2, 2013 at 6:33 PM, Paul Moore <pmo...@redhat.com> wrote: > On Wednesday, October 02, 2013 03:55:49 PM Joe MacDonald wrote: >> Hi all, > > Hello. > >> The first of these is just a minor tweak that makes it possible for me to >> use the existing INSTALL_BIN_MACRO when installing the other components in >> the tools/ directory. > > Okay, I'll take a look; that sounds reasonable to me. > >> I broke the python changes out into a separate commit because I'm not sure >> it's the right thing to do at all and I'm not sure I did it in a sensible >> way. >> >> The middle one is the one I care about (and have tried in my own scenario), >> though. It is convenient to have the regression tests able to run on a >> system that isn't the one I built libseccomp on originally. Any interest >> in this? > > The tests are there to help us, the libseccomp devs, and perhaps the > packagers, catch problems in the development and packaging stages, it isn't > something a user, or even an application developer, would ever find useful. > For this reason I don't want to install the tests. > > However, as usual, I'll keep an open mind on the issue. If you can convince > me that the advantages outweigh the disadvantages we can revisit the idea. I'm not sure that there's a huge win or loss either way, though I can certainly see your point of view. As it turns out the whole reason I started down this path is from a packaging point of view. I'm using libseccomp with some Yocto/OE configurations and they've got an infrastructure for doing package regression testing by using the packages' own self-testing. Looking at what libseccomp includes, I think it would fit well with that model and help me identify regressions that may either be due to packaging or cross-compilation that I wouldn't be able to (easily) find otherwise. They're not the sort of thing that would ever be installed by default in any regular build, but something that could be brought in for special case testing and, as in my case, a possible validation step before calling it done. The existing tests include, for example, bash and dbus self-tests, both of which I think fall into the same category as you've said the libseccomp tests land in, but I could very well be mistaken here as I've only really been following along libseccomp development until now, not using it much. -- Joe MacDonald :wq ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ libseccomp-discuss mailing list libseccomp-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
