One big resource would be Advanced Perl Programming. It has a number of sections on modules, both creation and maintenance.

The basic point behind modules is to encapsulate code that's used more than once by creating another namespace. (Don't worry about the namespace stuff, but remember it in the back of your mind.)

A standard package, if you're creating a set of functions to be used, would look something like:

use strict;
use 5.6.0;

package MyModule;

use Exporter;
our @ISA=qw(Exporter);

our @EXPORT_OK = qw(foo bar);

my $var1 = "Some value";

sub foo {
    ... # Maybe use $var1 here...
}

sub bar {
    ... # If not, use $var1 here.
}

1;
[download]

The 1; at the end is critical. Modules (or packages ... same thing) are pulled in with do, which requires that the last line be a true value.

$var1 is scoped so that ONLY functions within the package MyModule can access it. (That's not quite true, but you should code as if it is until you're more comfortable.)

Now, in your main program, you'd have a line similar to

use MyModule (foo);

That means that, in your main script, you can call foo() as if it was defined in your main script. However, you cannot call bar().

You've seen the use syntax a lot, I'm sure. If you put a symbol name (functions, usually) in @EXPORT (instead of @EXPORT_OK), then the function would be there, whether or not you requested it. A lot of CPAN modules that use Exporter do this, though it's generally considered somewhat rude programming style. (If you write a package like this, you're polluting my namespace, which is sorta rude if you think about it.)

This should be enough to give you an idea as to what questions you need to ask. I'm figuring that it's not that you don't know anything, cause that's obvious. It's more that you don't know what you don't know, which means you don't know what questions to ask.