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
