You say, "espcially if you use cfengine", yet the NAME heading says "System configuration related unit tests". So, I read that as this module is usable without that cfengine thing, but I still don't know how to use it. And it's good to also briefly mention about what cfengine is, what it does, and how it relates to your module. Is your module a Perl implementation of cfengine? Or instead, does it provides interfaces to cfengine?

I would say, go ahead and expand the module, but please allow the future users to understand what the module does. Briefly explain the idea, motivation, and purpose of the module. About the name, I suggest you're looking at the Sys:: namespace to put it under. I'm sure your module will fill some gap there :)

Oh one more thing, I didn't proceed to try your module because,

Test-Sysconfig-0.01$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_h
+arness(0, 'blib/lib', 'blib/arch')" t/*.tt/00-load.........# Testing 
+Test::Sysconfig 0.01, Perl 5.008008, /usr/bin/perl
t/00-load.........ok
t/01-sysconfig....ok 1/4
#   Failed test 'perl installed'
#   in t/01-sysconfig.t at line 11.
t/01-sysconfig....NOK 2/4# Looks like you failed 1 test of 4.
t/01-sysconfig....dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 2
        Failed 1/4 tests, 75.00% okay
t/pod-coverage....ok
t/pod.............ok
Failed Test      Stat Wstat Total Fail  List of Failed
----------------------------------------------------------------------
+---------
t/01-sysconfig.t    1   256     4    1  2
Failed 1/4 test scripts. 1/7 subtests failed.
Files=4, Tests=7,  1 wallclock secs ( 0.63 cusr +  0.16 csys =  0.79 C
+PU)
Failed 1/4 test programs. 1/7 subtests failed.
make: *** [test_dynamic] Error 255

Test-Sysconfig-0.01$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=linux, osvers=2.6.9-22.18.bz155725.elsmp, archname=i386-lin
+ux-thread-multi
    uname='linux hs20-bc1-6.build.redhat.com 2.6.9-22.18.bz155725.elsm
+p #1 smp thu nov 17 15:34:08 est 2005 i686 i686 i386 gnulinux '
[download]

Update: I didn't see any reply yet, even hours after I front-paged it in hoping to get more attention. So I just gave it a shot, eventhough I wasn't sure I understood about the module.

Thanks for your reply. You're right, my module is documented rather poorly. I'll be fixing that, but to briefly clarify here, the module has little to do with cfengine, aside from the fact that I use it to test my cfengine config on a staging server, before pushing it out to production.

As for check_package and file_contains, they check that a package exists and that a file's contents match a regexp, respectively. They call ok() (as in Test::Builder::Module's ok())

The failed test was a silly oversight on my part. I'd forgotten that some systems don't use dpkg and apt :). I'll have it skip that test on non-dpkg systems.

I've fixed the tests to work correctly on a non-dpkg system and clarified the docs quite a bit (I think :). Here is the fixed version. The Sys:: namespace seems like a good idea; I'm thinking something like Sys::ConfigTest... will ponder that for a bit.

Thanks again for taking the time to review this, and the great advice. ++.

I see some improvements on the docs, and I now I understand what your module is trying to do. I just don't have yet a chance to find out if similiar solutions exist on CPAN. Some notes:
• You may want to reconsider the check_package implementation because it's too centric on one favor of distro. I'm afraid that it's not that simple to verify that a package really exists, or even "usable" on the current system being tested.
• I see that file_contains is some kind of another grep implementation. You just can't take arbitrary string and treat is a regex. It could blow your module and something happens you don't expect.
• It's good to put a "SEE ALSO" section at the bottom of the POD and put Test::Builder::Module there, so users know where to find more information you don't need to provide
Overall, I strongly recommend you to dig more on CPAN to find out 1) the more flexible and generic way to check package availability 2) the safer way to check file content with regex (think eval), there is a number of File:: modules you may find useful (althought you don't have to use them); also you may want to improve it so your module can check more than one pattern in the target file.

Out of all, I'd still say, go ahead. Please be explicit that it's currently implemented for specific distro of specific operating system. If you find it useful for you, others may find it useful for them as well. And if they use different distro/OS, hopefully they implement that part for you. Good luck, jagh!

---

Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!