Hello...
On Fri, 2008-10-17 at 11:24 -0500, Chris Adams wrote:
> Once upon a time, D Canfield <[EMAIL PROTECTED]> said:
> > The problem is that older versions of these modules are included in
> > the main perl RPM. So, even though I have newer subpackages that I
> > could recompile, they will conflict with perl itself. And yes, I
> > could just build the packages with CPAN, but that defeats the purpose
> > of RPM in the first place.
>
> Are you sure they'll actually conflict? Multiple RPMs can have the same
> virtual provides; conflicts only come when the files overlap I believe.
> Since the module included with perl is in the base perl directory and
> any module you build will go in site_perl (or vendor_perl if you use
> cpanspec), there should be no file conflicts.
>
> Also, perl will look in site_perl/vendor_perl for modules before the
> base directory, so that shouldn't be a problem either.
>
yes
> The only problem you might have would be with any man pages; the easiest
> solution would be to exclude them from your RPM ("perldoc <module>" will
> follow the same search path as perl itself).
I use something like this in my perl module spec files:
export PERL_MM_USE_DEFAULT=true
CFLAGS="$RPM_OPT_FLAGS" perl Makefile.PL -- MAN1EXT=1cpan MAN3EXT=3cpan
PREFIX=$RPM_BUILD_ROOT%{_prefix} INSTALLDIRS=site
make OPTIMIZE="$RPM_OPT_FLAGS"
--
Christopher McCrory
"The guy that keeps the servers running"
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list