The Porting/Glossary file states WRT "inc_version_list":

 inc_version_list (inc_version_list.U): 

This variable specifies the list of subdirectories in over which perl.c:incpush() and lib/lib.pm will automatically search when adding directories to @INC. The elements in the list are separated by spaces. This is only useful if you have a perl library directory tree structured like the default one. See INSTALL for how this works. The versioned site_perl directory was introduced in 5.005, so that is the lowest possible value.

For "otherlibdirs" it says:

otherlibdirs (otherlibdirs.U): 

This variable contains a colon-separated set of paths for the perl binary to search for additional library files or modules. These directories will be tacked to the end of @INC. Perl will automatically search below each path for version- and architecture-specific directories. See inc_version_list for more details.

Now, to the uninformed Monk like myself, these plain-English explanations are not so plain. The latter refers to the former, strengthening the impression that these two settings do just the same thing. Is this some configuration cruft? or is there really some difference in how they behave?

Looking to INSTALL for greater enlightenment left me decidely unfufilled. The section headed

Coexistence with earlier versions of perl5

indeed discusses the issue but manages to avoid giving a single instance of an example of how the configurations shown were achieved. One part reads:

suppose you now install 5.8.0, which is not binary compatible with 5.6.0. The directories searched by 5.8.0 (if you don't change the Configure defaults) will be:

    /usr/local/lib/perl5/5.8.0/$archname
    /usr/local/lib/perl5/5.8.0
    /usr/local/lib/perl5/site_perl/5.8.0/$archname
    /usr/local/lib/perl5/site_perl/5.8.0

    /usr/local/lib/perl5/site_perl/5.6.0

    /usr/local/lib/perl5/site_perl/5.005

    /usr/local/lib/perl5/site_perl/     

Note that the earlier $archname entries are now gone, but pure perl modules from earlier versions will still be found.

This text is showing the results or effects of configure-time choices, not the choices themselves. I do grasp the principle being elucidated, I think. The point of the above section (should be read in toto for best understanding) is that recent Perls have built-in intelligence (read: heuristics) about architectural and BPI compatibility. So, if I grasp the material correctly (and Oh! Good Monks! I pray that you'll shed your illumination on me either way), one should only need to do a specification at Configure-time, of the top of the area in one's filesystem where there are Perl modules from earlier installations to be found. For instance, going by the above example, I'd want to do:

 -Dotherlibdirs=/usr/local/lib/site_perl 

somewhere on the command line (or equiv.) in order to achieve the above result. Or is it

 -Dinc_version_list=/usr/local/lib/site_perl 

or is it neither, or both, but done differently? For example, is inc_version_list intended to be done like

 -Dinc_version_list="5.8.0 5.6.1"  

as a way of mediating what versions Perl is allowed to consider when it looks at the top dir specified in otherlibdirs? If so, why would one ever need to do that?

Please provide me with informed insight concerning this holy mystery.

    Soren/Intrepid

-- 
"No matter what algorithm I try, I can't find the substring 'sh'
anywhere in the string 'CMD.EXE'!"