How do folks deal with perl conflicts? We normally use RPMs for
everything but that’s not practical given the relatively high-version
requirements of the rt4 branch so CPAN seems the only practical
approach.
Ideally we would do installs with directives to force installations to
be local (defining INSTALLARCHLIB , MAN1, MAN3 etc) but several of
the dependent modules ignore those directives and fail as they want to
install into /usr/… etc which requires root which we don’t want to
give to CPAN.
Any ideas here?
thanks
ram
PS currently we use a dedicated VM for rt where it’s allowed to wreak
havoc on the system but I’d like to neaten it up into an apache VHOST
like our other http services…
How do folks deal with perl conflicts? We normally use RPMs for
everything but that’s not practical given the relatively high-version
requirements of the rt4 branch so CPAN seems the only practical
approach.
Use a completely separate build of perl just for RT instead of the
system installed and managed perl.
Look at perlbrew for an easy way to build perl if you’re not familiar
with the process.
How do folks deal with perl conflicts? We normally use RPMs for
everything but that’s not practical given the relatively high-version
requirements of the rt4 branch so CPAN seems the only practical
approach.
Use a completely separate build of perl just for RT instead of the
system installed and managed perl.
Look at perlbrew for an easy way to build perl if you’re not familiar
with the process.
I agree that’s probably the most pain-free and robust method.
On my Mac, where I do some RT tinkering as a standalone build, I have an rt-support directory in my home directory, and I put all the libraries RT needs in there, and I point my PERL5LIB and DYLD_LIBRARY_PATH variables at it whenever I’m working on RT. The relevant bits of my CPAN/MyConfig.pm file:
‘makepl_arg’ => q[INSTALL_BASE=~/rt-support],
‘mbuildpl_arg’ => q[–install_base ~/rt-support],
and then my PERL5LIB is:
$HOME/rt-support/lib/perl5
On my production RT server, which is running Ubuntu, I use the system perl, and install pre-packaged modules where I can, but if I can’t I just let RT’s ‘make fixdeps’ do what it likes, and install the necessary packages in the system’s site perl directory. Since the server isn’t used for anything other than RT, I’m not bothered about superseding what the OS itself installs. The major advantage of doing it that way is that it’s then much easier to configure with the packaged versions of apache, mod_perl and so on.
Tim
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Date: Wed, 31 Oct 2012 10:10:56 +0000
From: Tim Cutts tjrc@sanger.ac.uk
To: Thomas Sibley trs@bestpractical.com
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Perl conflicts
Message-ID: B823EDDB-03A1-4BD4-BC4F-E5C6DE19C2A8@sanger.ac.uk
Content-Type: text/plain; charset=us-ascii
How do folks deal with perl conflicts? We normally use RPMs for
everything but that’s not practical given the relatively high-version
requirements of the rt4 branch so CPAN seems the only practical
approach.
Use a completely separate build of perl just for RT instead of the
system installed and managed perl.
Look at perlbrew for an easy way to build perl if you’re not familiar
with the process.
I agree that’s probably the most pain-free and robust method.
On my Mac, where I do some RT tinkering as a standalone build, I have an rt-support directory in my home directory, and I put all the libraries RT needs in there, and I point my PERL5LIB and DYLD_LIBRARY_PATH variables at it whenever I’m working on RT. The relevant bits of my CPAN/MyConfig.pm file:
‘makepl_arg’ => q[INSTALL_BASE=~/rt-support],
‘mbuildpl_arg’ => q[–install_base ~/rt-support],
and then my PERL5LIB is:
$HOME/rt-support/lib/perl5
Yep this is exactly what we’ve tried but some of the required modules
do not respect those parameters (INSTALL and MANPAGE). We started to
tweak the perl make files for those modules one by one but it’s not a
great way to go.
On my production RT server, which is running Ubuntu, I use the system perl, and install pre-packaged modules where I can, but if I can’t I just let RT’s ‘make fixdeps’ do what it likes, and install the necessary packages in the system’s site perl directory. Since the server isn’t used for anything other than RT, I’m not bothered about superseding what the OS itself installs. The major advantage of doing it that way is that it’s then much easier to configure with the packaged versions of apache, mod_perl and so on.
Our server runs CentOS 6 (downstream of RHEL 6) and it is no small
feat to get most of the perl modules as rpms, it is impossible to get
them all without building them ourselves.
Any other ideas?
thanks
On my Mac, where I do some RT tinkering as a standalone build, I have an rt-support directory in my home directory, and I put all the libraries RT needs in there, and I point my PERL5LIB and DYLD_LIBRARY_PATH variables at it whenever I’m working on RT. The relevant bits of my CPAN/MyConfig.pm file:
‘makepl_arg’ => q[INSTALL_BASE=~/rt-support],
‘mbuildpl_arg’ => q[–install_base ~/rt-support],
and then my PERL5LIB is:
$HOME/rt-support/lib/perl5
Yep this is exactly what we’ve tried but some of the required modules
do not respect those parameters (INSTALL and MANPAGE). We started to
tweak the perl make files for those modules one by one but it’s not a
great way to go.
As you see above, I don’t set the individual locations like INSTALL and MANPAGE. Just the INSTALL_BASE. I have not found a single CPAN module that RT requires which did not install correctly in my ~/rt_support directory. Which ones did you have problems with?
On my production RT server, which is running Ubuntu, I use the system perl, and install pre-packaged modules where I can, but if I can’t I just let RT’s ‘make fixdeps’ do what it likes, and install the necessary packages in the system’s site perl directory. Since the server isn’t used for anything other than RT, I’m not bothered about superseding what the OS itself installs. The major advantage of doing it that way is that it’s then much easier to configure with the packaged versions of apache, mod_perl and so on.
Our server runs CentOS 6 (downstream of RHEL 6) and it is no small
feat to get most of the perl modules as rpms, it is impossible to get
them all without building them ourselves.
On Debian/Ubuntu systems there’s a fabulous little package called dh-make-perl which whizzes off to CPAN, downloads the module sources, configures and builds it and results in a .deb package which you can install on the system. Before RT 4.0 came out, that’s how I built all the perl modules for our RT server. It was a nice clean way to do it, if a bit of a faff. Does CentOS have a similar script for making RPM’s out of CPAN modules?
Regards,
Tim
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Any other ideas?
It’s worlds-apart easier and less error prone to use an entirely
separate perl build instead of just a separate perl lib path. See perlbrew.
Any other ideas?
It’s worlds-apart easier and less error prone to use an entirely
separate perl build instead of just a separate perl lib path. See perlbrew.
+1 It is much, much easier and basically foolproof. Using the separate
perl lib path is definitely harder to get right and requires more package
config jiggering. From most to least work:
- system perl + CPAN
- RT specific perl + CPAN
- RT specific perl lib path + CPAN + config tweaking
Cheers,
Ken
On my Mac, where I do some RT tinkering as a standalone build, I have an rt-support directory in my home directory, and I put all the libraries RT needs in there, and I point my PERL5LIB and DYLD_LIBRARY_PATH variables at it whenever I’m working on RT. The relevant bits of my CPAN/MyConfig.pm file:
‘makepl_arg’ => q[INSTALL_BASE=~/rt-support],
‘mbuildpl_arg’ => q[–install_base ~/rt-support],
and then my PERL5LIB is:
$HOME/rt-support/lib/perl5
Yep this is exactly what we’ve tried but some of the required modules
do not respect those parameters (INSTALL and MANPAGE). We started to
tweak the perl make files for those modules one by one but it’s not a
great way to go.
As you see above, I don’t set the individual locations like INSTALL and MANPAGE. Just the INSTALL_BASE. I have not found a single CPAN module that RT requires which did not install correctly in my ~/rt_support directory. Which ones did you have problems with?
My mistake; the issue seems to be that, in trying out the various
build variables, mbuildpl_arg was left with INSTALL_BASE rather than
–install_base…
On my production RT server, which is running Ubuntu, I use the system perl, and install pre-packaged modules where I can, but if I can’t I just let RT’s ‘make fixdeps’ do what it likes, and install the necessary packages in the system’s site perl directory. Since the server isn’t used for anything other than RT, I’m not bothered about superseding what the OS itself installs. The major advantage of doing it that way is that it’s then much easier to configure with the packaged versions of apache, mod_perl and so on.
Our server runs CentOS 6 (downstream of RHEL 6) and it is no small
feat to get most of the perl modules as rpms, it is impossible to get
them all without building them ourselves.
On Debian/Ubuntu systems there’s a fabulous little package called dh-make-perl which whizzes off to CPAN, downloads the module sources, configures and builds it and results in a .deb package which you can install on the system. Before RT 4.0 came out, that’s how I built all the perl modules for our RT server. It was a nice clean way to do it, if a bit of a faff. Does CentOS have a similar script for making RPM’s out of CPAN modules?
There are tools to do it (cpan2rpm comes to mind) and of course
something like perlbrew (oft mentioned in this type of discussion)
which I believe that compiles things into ‘executables’. The above
solution is the best I can do IMO since it’s unrealistic to expect all
the perl modules needed to show up in rpms for every OS though there
are no shortage of folks maintaining RPMs that are happy to build them
for whatever perl module you want (Dag and rpmforge come to mind for
CentOs).
Thanks again, I think seeing you write it out let to my getting it working!
ram
Date: Wed, 31 Oct 2012 10:25:31 -0700
From: Thomas Sibley trs@bestpractical.com
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Perl conflicts
Message-ID: 50915F0B.3050800@bestpractical.com
Content-Type: text/plain; charset=UTF-8
Any other ideas?
It’s worlds-apart easier and less error prone to use an entirely
separate perl build instead of just a separate perl lib path. See perlbrew.
Might’ve taken this path if tweaking configs didn’t work out. Thanks
for the suggestion.
ram
There are tools to do it (cpan2rpm comes to mind) and of course
something like perlbrew (oft mentioned in this type of discussion)
which I believe that compiles things into ‘executables’.
perlbrew doesn’t compile Perl modules into executables. perlbrew
compiles a whole another installation of perl for you, so that you don’t
have to use /usr/bin/perl. Once you’re using your new perl, you can
install whatever modules you want from CPAN without wasting time getting
build and install paths correct everywhere.
Date: Wed, 31 Oct 2012 12:47:49 -0500
From: “ktm@rice.edu” ktm@rice.edu
To: Thomas Sibley trs@bestpractical.com
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Perl conflicts
Message-ID: 20121031174749.GV2872@aart.rice.edu
Content-Type: text/plain; charset=us-ascii
Any other ideas?
It’s worlds-apart easier and less error prone to use an entirely
separate perl build instead of just a separate perl lib path. See perlbrew.
+1 It is much, much easier and basically foolproof. Using the separate
perl lib path is definitely harder to get right and requires more package
config jiggering. From most to least work:
- system perl + CPAN
- RT specific perl + CPAN
- RT specific perl lib path + CPAN + config tweaking
Cheers,
Ken
Thanks again Ken.
Looks like #2 is the way we’re going.
Ram