Why is it causing a problem? According to perlmod, "use Module" is exactly like BEGIN { require Module; import Module; } - thus "use Audit::Config" is like BEGIN { require Audit::Config; import Audit::Config; }. Perl will go looking in the Audit::Config namespace for a function called "import". It will fail because the package loaded by the require Audit::Config part of that code really was Config rather than Audit::Config.

Once you change the package to match the filename, with its full path, in proper perl convention, perl can now find the import sub in Audit::Config. "Wait a minute!" you may say. "I don't have an import sub in Audit::Config. I scanned my entire file - even the parts I didn't post!" Ah, but you do! It is placed there by the fact that you're deriving from Exporter! How convenient is that! Unfortunately in this case, there are some perl conventions that are actually hard-and-fast rules which brought you some headaches. In many cases, the fact that the package name doesn't line up with the bareword passed to "use" is a minor detail - just a convention without a requirement. However, many modules, including Exporter, assume that you follow convention and ... well, you get to post your code to PerlMonks :-)

Makes sense...Thanks for that. :-)

For example, to start a traditional, non-OO module called Some::Module
+,
create a file called Some/Module.pm and start with this template:

    package Some::Module;  # assumes Some/Module.pm
[download]

Sorry that should have read:

package Check::DNSCheck;

Serves me right for not copying and pasting. :-\

Then you probably meant Check::DNSCheck->new

This assumes there is a file Check/DNSCheck.pm containing package Check::DNSCheck;, and the script includes use Check::DNSCheck;