in reply to On providing documentation with your modules
Your wrapper most likely contains perl based functions, right? Does each and every one of these perl functions do the same thing as their BLAST equivalents? If they don't, I would write a short blurb about the functions. You don't need to be extremely verbose, just saying "foo($bar) is the same as the bass equivalent of foo(int bar), and the return value will always be a hash instead of the bass char" So, if everything is exactly the same I see no problems with referring people to other documentation. But if it isn't, be sure to document the changes, so people don't have to screw with them to figure out how they work.
CGI.pm is a good example of how you don't always have to document all of your features for the documentation to be successful. For instance, CGI.pm uses function which are named after their corresponding HTML tags. So, the POD has a section where it explains that if it's available in HTML, it's a function spelled with lowercase letters. IMHO, this makes the documentation much more concise because it doesn't have a list of functions which all do the same thing, and is a great way to go.
Want to support the EFF and FSF by buying cool stuff? Click here