I'm not sure exactly what you're looking for. "Inheritance" is a term specific to object oriented programming that describes one way to say "This thing acts like this other thing, perhaps with some small changes."

Inheritance may be one way to solve what you're doing here, but I don't think it is.

You have a couple of options for making one variable or object available across multiple modules:

• Make it a global and always access it via a namespace, with something like $DB::Package::dbh. This has the drawback that you can't control who reads from or writes to it. That can be hard to debug.
• Add it to the export list wherever you need it. This is still effectively a global variable, but it's a little less messy.
• Store all of the database-related stuff in an object or package of its own and don't let it leak out anywhere else. This is a good practice anyway because it's easier to find what you need to change and because with good encapsulation it's more difficult to change things elsewhere accidentally.
• Add an accessor to your database-related module from which to retrieve your database handle and only ever grab it via the accessor, perhaps my $dbh = DB::Package->fetch_dbh().

There are other options, but they're mostly variants of these strategies. I do suggest modularizing your code by behavior and duty, though. It has many other benefits.

To export something from a module you need to use:

use Exporter;  # require works;
@ISA = 'Exporter';
@EXPORT_OK = qw(functions $variables @arrays);
# I put this after the above, some put this above and then use "our".
use strict;
[download]

What you wrote, by contrast, has several syntax errors, forgets that Perl is case-sensitive, and has some more subtle mistakes (eg the , inside of qw()). One of the more subtle mistakes is choosing to use @EXPORT instead of @EXPORT_OK, which works, but which will make debugging much harder. (Where did this come from?)

As for the question that you're asking, the simple way to do it is to use fully qualified package names. Like this:

# In the main script...
use strict;
use vars qw($foo);
# ... time passes ...
$foo = "whatever";

# In the module...
print $main::foo;
[download]

PS: Note that I've pushed you towards using strict.pm. There are good reasons for that...

@EXPORT instead of @EXPORT_OK, which works, but which will make debugging much harder

This is not related to debugging.

The difference is that subs and vars included in @EXPORT will always be exported to the modules use'ing the module, while on the other hand, things included on @EXPORT_OK will only be exported when explicitely requested on the use statement.

The problem with @EXPORT is namespace pollution that leads to name collisions when exported functions are added in new versions of some module.

There is also a debugging problem. Two of them in fact.

The first debugging problem is figuring out what happened after name collisions. (Creating bugs leads to debugging...) The second, and to me more important, one is the added trouble in finding the functions and variables that you see being called and accessed.

The difference is that subs and vars included in @EXPORT will always be exported to the modules use'ing the module...

Not to be overly retentive here, but that's not quite right. Or at least not sufficiently clear. In the empty list case -

use Some::Module ();

- no symbols are exported, even the ones in @EXPORT. In fact, @EXPORT are only imported in the default (unspecified) case. If you specify your imports explicitly, then you only get what you ask for.