Michael Schout writes: > example, one time we upgraded Apache::Filter between releases. > Unfortunately, the old version was not compatible with the new version, > so a single machine could run either the current release branch, or the > development branch, but not both simultaneously (because Apache::Filter > was incomptaible and was installed under /usr/lib/perl5).
We are transitioning (slowly) between perl 5.005 and 5.6.1. Our trick is to have separate 5.005 and 5.6.1 build/test (and sometimes dev) machines. I'm not sure this solves your problem. > 1) some Makefile.PL's refuse to generate a Makefile if PREREQ_PM's are > not satisfied (if we haven't built them yet) If we have to bootstrap, we do a regular CPAN install on the build machine and then install over it with the RPM build. Also, we use Red Hat which has many CPAN modules already installed (see uninstall instructions below), so bootstrapping is rarely an issue. > 2) some Makefile.PL's are INTERACTIVE, and you cant turn it off (e.g.: > Apache::Filter requires you to hit <Return> a number of times at a MINIMUM. "perl Makefile.PL < /dev/null" works for us. We encapsulate it in a macro (see below). > So we resorted to a set of overly-complicated GNUmakefiles that would > generate Makefile's from Makefile.PL's, and these would set PERL5LIB to > find the dependencies (e.g.: DBD-Pg would put ../DBI/blib into > PERL5LIB). Here's our spec file: Name: perl.modules Summary: Perl Modules not in stock RH7 Group: Perl/Modules Provides: perl.modules perl-libwww-perl Requires: perl Version: 5.6 BuildRoot: install %define modules BSD-Resource IO-stringy Digest-MD5 Digest-HMAC Digest-SHA1 MD5 Crypt-IDEA Crypt-DES Crypt-Blowfish Crypt-CBC DBI DBD-Pg DBD-Oracle DBD-Sybase DBD-mysql TimeDate MailTools MIME-tools Devel-Symdump Image-Size Compress-Zlib Archive-Zip File-MMagic TermReadKey Crypt-SSLeay libwww-perl Parse-RecDescent Mail-Field-Received POP3Client Mail-2IMAPClient Test-Simple Time-HiRes Digest-Nilsimsa razor-agents Mail-Audit Mail-SpamAssassin XML-XPath httpmail %description Perl Modules not in stock RH7 or newer CPAN versions. To remove RedHat standard installs, do: rpm -e --nodeps $(rpm -qa | egrep 'perl-(DBD|DBI|libwww)') If you want to use Sybase (SQL Server), you need: b-release install freetds-0.53-1.i386.rpm And to compile this, you need: b-release install freetds-devel-0.53-1.i386.rpm %prep %{cvs} external/perl-modules-5.6 %build cd external/perl-modules-5.6 unset PERL_MM_OPT for f in %{modules}; do ( if test $f = 'Crypt-IDEA'; then export PERL_MM_OPT='POLLUTE=1' elif test $f = 'DBD-Sybase'; then export SYBASE=/usr elif test $f = 'DBD-Pg'; then export POSTGRES_LIB=/usr/lib POSTGRES_INCLUDE=/usr/include/pgsql fi cd $f %{perl_make} ) done %install cd external/perl-modules-5.6 for f in %{modules}; do (set -e; cd $f; %{perl_make_install}) done cd $RPM_BUILD_ROOT %{allfiles} >../files %files -f files %clean [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT %pre # Perl must be setup properly perl -e 'require "syscall.ph"' 2> /dev/null || ( umask 022 cd /usr/include h2ph -r -l . > /dev/null ) The macros perl_make_install and perl_make are defined below. We run a program (Bivio::Util::Release mentioned in another post) which generates the actual spec file and calls rpm. (%{allfiles} and %{cvs} are trivial and defined there, too.) This program also builds a separate directory and defines topdir, etc. correctly so you can build everything as any user. sub _perl_make { return '%define perl_make umask 022 && perl Makefile.PL < /dev/null && ' . " make POD2MAN=true\n" . '%define perl_make_install umask 022; make ' . join(' ', map { uc($_) . '=$RPM_BUILD_ROOT' . $Config::Config{$_}; } grep($_ =~ /^install(?!style)/ && $Config::Config{$_} && $Config::Config{$_} =~ m!^/!, sort(keys(%Config::Config)))) . ' POD2MAN=true pure_install && ' . ' find $RPM_BUILD_ROOT%{_libdir}/perl? -name "*.bs" ' . " -o -name .packlist -o -name perllocal.pod | xargs rm -f\n"; } [Uh oh, there's that nasty map function. ;-] Note that we don't install man pages. This slows down the build/install, and perldoc is just as easy to type as man. :-) We use this same function for all our perl apps. Indeed, to build a new app, our specfile looks like: Copyright: Logistics R Us, Inc. Requires: Bivio-bOP apache ImageMagick-perl %define perl_root LogisticalNightmare %define perl_exe_prefix ln _b_release_include('perl-app.include'); perl-app.include knows how to read our tree structure, which is consistent across projects, and it installs all perl, programs, images, views, etc. > How does everyone else cope with this (managing trees of CPAN modules / > CPAN module tree build environments)? Maybe we are sort of unique in > that we use so many 3rd part CPAN modules, but because we use so many of > them its pretty critical that we manage them in CVS. You're not unique afaik. It's a hard problem. We try to use stock Red Hat when we can, but sometimes we need more recent versions or we have to fix defects. Rob