(Rhys -- I see you've fleshed it out quite a bit since we chatted in the CB.)

How 'bout having your perl app read the dir list from a config file? This not only lets you change you mind about the MIBDIR layout, but keeps the changes confined to the app's process tree and lets your end users choose different MIBs than yours, should they wish to extend your app.

In fact, with that, you could even keep your MIBs completely out of the common hierarchy.

Okay, I've got good news and bad news.

The good news is that this will mostly work, and I can add several things to the list of stuff I no longer have to worry about.

The bad news is I have to add new code to any module that needs to load MIBs. The new code is as follows:

@DIRS = `ls -1d /usr/local/share/snmp/mibs/TEMP/*`;
foreach $dir ( @DIRS ) {
        chomp $dir;
        &SNMP::addMibDirs("$dir");
}
[download]

Anyway, some more detail on the advantages:
1. I don't have to modify environment variables. This is good because if $ENV{MIBDIRS} is previously unset, you have to find out where the site-wide MIBs are stored. While this is usually predictable, I'd rather not worry about it at all.
2. I don't have to modify environment variables. By adding the package's own base MIB directory to the config file, the change can be made effective site-wide (using the config file in /etc) without worrying about users' various shells, changing their environments, etc.
3. I can actually eliminate a config item I used to have in the code that kept track of the location of the site-wide MIBs that come with Net-SNMP. Again, less to worry about.
4. In the course of investigating this, I've discovered the proper use of the &SNMP::loadModules() function AND I've learned enough about duplicate MIB detection that the package's own code will be a lot leaner and the post-install script can do a lot more to detect duplicates (thus avoiding several really annoying MIB problems I've had before).
I may even write a separate script just to detect duplicates, since the user has a nasty tendency to do that. :-)

Anyway, I want to thank all those who offered suggestions. Hopefully this will be the last time I have to worry about this. :-D

--Rhys

Additional information: Net-SNMP comes with a handy little script that - if it's in the user's PATH - helps find the site-wide MIBs. E.g.:

$SITE_PREFIX = `net-snmp-config --prefix`;
chomp $SITE_PREFIX;
$DEF_MIB_DIR = "$SITE_PREFIX/share/snmp/mibs";
[download]

I should be able to create a subdirectory under that named after my package, then subdirs as usual. Then use the addMibDir() trick above combined with the readdir() method suggested by idsfa, and I think we're there!

I'll still want to add some exception handling code for the cases where net-snmp-config can't be found or the MIB files were moved (e.g. can't stat "$SITE_PREFIX/share/snmp/mibs"), and some other stuff. Might put some user-prompting in there for help, but this is getting close.

--Rhys

You could extend the SNMP class to add your needed code to the mib loading method and then SUPER:: it. This would probably be more work than adding the few lines you need.

Also, you probably ought to avoid that `ls` construction and go with readdir ...

$root="/usr/local/share/snmp/mibs/TEMP";
opendir(DIR, $root) || die "can't opendir $root: $!";
map { &SNMP::addMibDirs($_); } 
          grep { ! /^\./ && -d "$root/$_" } readdir(DIR);
closedir DIR;
[download]

Which also avoids accidentally trying to add files as MibDirs and is safer and more portable.

---

Remember, when you stare long into the abyss, you could have been home eating ice cream.