Re^2: Checking and installing a perl module

Replies are listed 'Best First'.
Re^3: Checking and installing a perl module by Bloodnok (Vicar) on Jun 11, 2009 at 17:31 UTC
Are there underlying (and self-evidently, unstated) reason(s) why you don't use NFS mounted extra libraries ?? In that way, you remove the need to maintain libraries across a load of disparate machines (and installations) with all the attendant problems - at least one of which, you've now encountered. A user level that continues to overstate my experience :-))	[reply]
Re^4: Checking and installing a perl module by vek (Prior) on Jun 11, 2009 at 22:03 UTC
Off the top of my head, reasons why I might not want to use NFS mounted extra libraries. • Network latency. The dreaded slow NFS mount problem. Added program startup penalty. • NFS mount goes away. Whoops. Now your program won't compile. • Perhaps you don't want the exact same module version on every host. -- vek --	[reply]
Re^5: Checking and installing a perl module by Bloodnok (Vicar) on Jun 12, 2009 at 10:04 UTC
I concur with your point wrt library version - but, even so, differing versions can be mitigated for by having a base/stable version installed in the NFS mounted library and a different version installed locally to the machine as necessary - assuming a suitable `PERL5LIB`, perl on that machine will thus pick up the localised version in preference to the base/stable version. I infer from Network latency. The dreaded slow NFS mount problem... that you're only considering auto/soft mounts - a hard mount will remain for as long as the mount server is providing the resource &/or the network is up. From NFS mount goes away..., I take it that either your network &/or your mount server aren't as stable as most... Overall, it appears as though the local installation of libraries is the preferred, labour intensive work-round for network problems... A user level that continues to overstate my experience :-))	[reply] [d/l]