I'm inclined to agree with shmem, though perhaps not quite so vehemently. I believe your reasoning is fine, but does not stand on its own. There are other issues, if ignored could lead you to these conclusions much faster than you should.

First and foremost, as shmem stated, "if it ain't broke, don't fix it." In the old days, when distros first started packaging extras like PERL with their own package managers, odds were, it was broken except for the most trivial needs. Again as already stated, those days are **mostly** past. Therefore, the exercise of asking yourself if you are really on one of those few, still busted up distros, should be asked BEFORE all the other questions you list.

Second, and almost as important, never, ever, never, ever mix and match maintenance paths. The vendor provided perl distro should never have CPAN invoked on it. While that may not seem like an issue from a PERL developer standpoint it is a nightmare from a System Administrator standpoint. It breaks anything but the most trivial maintenance processes and positively does not scale. If you must inject non-vendor supplied packages, it should be done along side the vendor supported mechanism (eg. for Red Hat that would be by installing an rpm) from a locally managed library. This allows your solution to scale using things like Puppet and other products without having to apply a sledge hammer and crowbar to the mix.

It helps if you clarify for yourself what you intend to support. If you support the OS, then you should install to that OS in the manner expected by the OS. If you support an Application, then that application is limited to what is supplied by the OS (and it's support mechanism). If you install both PERL and an Application, then you are supporting BOTH! That's why when companies like Oracle or Google install a product, the supporting products they need are usually buried in the application directories. No one else is expected to use or monkey with them. As far as the Sys Admin is concerned, Application SpiffySoft was just installed. Not SpiffySoft and its own PERL distro. Again, that distro should never be managed by CPAN as that invites disaster. It is managed by patches/updates from SpiffySoft Corp. If you must manage multiple PERL installations, it should be due to "reasonable" incompatibilities between products and even then, in today's world, you are probably better off creating virtual or chroot'd environments to keep them separated.

In short, before committing to the path of maintaining separate PERL distros on the same machine, first examine why you've gotten yourself into that pickle to begin with. Make sure you have not committed some other fatal mistake that should be fixed first. Second, examine your application feature set. Are those requirements needed for your app/platform (eg. due to a bug) or just because you want to use that slick cool module? Remember, the harder your application is to install and maintain, the less cool it becomes over time...

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.