Besides, adding eight or nine directories with names like '/usr/local/share/snmp/mibs/JScan/BayStack' to that variable would make it gigantic. Enormous variables have always annoyed me, and I kind of figured it annoyed others as well.

I'm not married to the opinion, though. If I should be modifying $ENV{MIBDIRS}, what's the best way to do it? Add a script to /etc/profile.d?

--Rhys

(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.

---

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

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