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.
I’m sorry, but you cannot expect RPM (or any other packaging system like DPKG,
etc.) to know ANYTHING about CPAN or the other way around. The two systems are
completely orthogonal and have VERY different philosophical views regarding
software management. RPM only wants to deal with RPM packages with their file
manifests, and CPAN is more like the BSD ports system in the fact that its a
source build, every time. Either you use RPMs or you risk breaking the
dependency chain on your system, which I as an experienced administrator DON’T
want to deal with.
The best solution is to get people willing to sponsor packaging RT for RH in
the EPEL repository, SuSE on the OBS, Mandriva contrib, and Debian Unstable.
(The reason for the given distributions listed is that should cover the major
flavours out there fairly well since anything in EPEL will be usable for
CentOS and RHEL; having it in OBS for SuSE would make it possible to have
releases for SLES 10-11 and OpenSuSE 11.x; Mandriva contrib since they’ve one
of the most comprehensive collection of Perl packages to any other RPM
distribution, and their flavour of RPM is not 100% compatible to RH, SuSE,
etc.; and Debian Unstable packages in most cases will work on Ubuntu for those
that want/need Ubuntu LTS compatibility.) Yes, it’s not perfect, but that’s
the breaks in the F/OSS world.
Upping the ante and requiring a person to manage the myriad of modules that RT
requires is a non-trivial task for non-Perl savvy people (I am well versed in
Perl so it’s no issue to me with my custom scripts to auto package them up
using cpan2rpm (generates specs for me which then are fed to my autobuilder),
but I can see where this could definitely impact the user base of RT overall.)
Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell: (650) 704-6633
Phone: (408) 240-1239