> those too parented in the site_perl tree. IMO, the need for a source > built/local build of Perl is NEVER a good solution to hand to users. Running a > ticketing tool shouldn't require a user to build a local copy of a core > distribution component. It's got nothing to do with RT. Existing package managers do not play well with Perl's modules/libraries. The same goes for any language that lets you install updates outside of the platform's rigid package system.
RPM's can execute initialization scripts, and there's no reason why RedHat shouldn't check to see what the *real* version of the library on disk is before blindly clobbering it. Your solution of "compile your own packages of potentially conflicting libraries that will install to site_perl" doesn't sound much friendlier than "use another perl." Arguably, a better solution would be for RT to use local::lib, but it's relatively new. -- Cambridge Energy Alliance: Save money. Save the planet. _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [email protected] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
