We think we found the problem - our Production Perl Environment was a little confused - we had scripts in XPP pointing to a directory that went away.

I'm glad that you found your problem. But  the answer to your question is a little complicated. The XPP documentation does state that for Linux the old 'perl' is removed and replaced with an updated version of PERL, so you must re-install any perl modules that may have been added. However, this only applies to XPP's perl that is delivered with XPP (LInux) at "/etc/xyvision/common/perl".

XPP does NOT touch any perl that is managed by the OS, so the /usr/share/perl5/LWP/Protocol is not part of XPP install and therefor out of bounds for anything that XPP would do. Of course if you are copying files around and//or creating soft-links between XPP and the OS, then  all bets are off and I can't answer to what happens to the /usr/share folder if it has been somehow linked into XPP's PERL.

What if the root account or the IT engineer has PERL5LIB variable set and it points to the Native Perl  PERL5LIB = /usr/share/perl5.   Would that have any impact on the install process.

We did notice that in our DEV and TEST environment we had to "unset PERL5LIB" to resolve conflicts between XPP Perl Modules and Native Perl Modules. - We added that to our global shell  xyv.cshrc

Yes, that may cause conflicts. You definitely do not want XPP's PERL pointing to and using modules from the /usr/share/perl library. Modules would be much older with lots of collisions.

UnsettingPERL5LIB for XPP usage is the best way to go. 

Yes, that may cause conflicts. You definitely do not want XPP's PERL pointing to and using modules from the /usr/share/perl library. Modules would be much older with lots of collisions.

UnsettingPERL5LIB for XPP usage is the best way to go.