Front page | perl.perl5.porters |
Postings from January 2003
Re: MakeMaker problems with relocation
From: Rob Brown
January 1, 2003 12:22
Re: MakeMaker problems with relocation
Message ID: Pine.LNX.firstname.lastname@example.org
On Sat, 28 Dec 2002, Axel Thimm wrote:
> I had already tried the fake-DESTDIR-embedded-in-PREFIX-at-build-time method
> with some rpms and they seem to work fine, even on non-RH platforms (Mandrake
> seems to be still very close to RH). What exactly goes wrong with the versions
> you have tested? (BTW there must be some typo, as you mention the same
Oh yeah, I meant between 5.6.0 and 5.6.1. (Erick
tried upgrading from perl 5.6.0 to 5.6.1, yet it
left the old MakeMaker in tact.) I meant the
versions of ExtUtils::MakeMaker that come with the
stock 5.6.0 and 5.6.1. Both have VERSION 5.45 but
are not the same. With the old 5.45 (from 5.6.0)
your method yields the same problems as putting
PREFIX= on the "perl Makefile.PL" line.
Try it on any module, like MailTools-1.53.tar.gz:
--- snip ---
perl Makefile.PL 'PREFIX=$(DESTDIR_CPAN2RPM)/usr'
make install DESTDIR_CPAN2RPM=/tmp/fake-root
--- snap ---
Notice "/perl5/" directory is totally gone! It
should probably be as follows:
So that is too borked to use. This very strange
behavior occurs on the old 5.45 version whenever
any args are passed on the "perl Makefile.PL"
line for some reason.
> I also just checked, what RH currently provides in the 8.1 beta, and it is
> still MakeMaker 6.03. I don't believe that we will ba able to persuade RH to
> switch to a newer version of MakeMaker (but we could try). I do not know what
> other distros are currently shipping, but I think MakeMaker 6.03 is part of
> perl 5.8.0. Probably this could mean that there will be a significant amount
> of the excluded range of MakeMaker versions existing in the near future.
Someone should tell Jarkko to grab the new MakeMaker
6.06 for the 5.8.0 distro. Unless Michael Schwern
has more stuff he wants to add before cooking it into
the core. (Actually, is Hugo taking over for this
now?) Then it should be pretty easy to persuade RH
to use the new MakeMaker.
> On Fri, Dec 27, 2002 at 04:01:33PM -0700, Rob Brown wrote:
> > [...] We have decided not to
> > support MakeMaker between 5.91 and 6.05 inclusive. Prior works okay with
> > PREFIX=/foo/usr and the recent ones work great with that new DESTDIR=/foo
> > parameter on the "make install" line. Those with MakeMaker between those
> > versions (i.e., rh 8.0) may upgrade to MakeMaker 6.06 or higher, then
> > cpan2rpm works fine again. Since MakeMaker builds itself recursively (with
> > itself), cpan2rpm can be used on a rh 8.0 box to build and install MakeMaker
> > just fine. Only after this is upgraded can other cpan modules be installed.
> > So there's no "chicken-and-egg" issue to worry about.
> BTW about building MakeMaker with cpan2rpm - If one provides a MakeMaker rpm,
> it will conflict with the perl rpm itself, as MakeMaker is not provided as a
> separate rpm. Thus, one would need to replace the perl rpm for upgrading
Nope, since perl's @INC order is still broken, ("core"
coming BEFORE "site" and "vendor" instead of AFTER),
I've added a --shadow-pure option to force the module
installation into installarchlib which comes before
installprivlib and even all the site and vendor
directories. This only works with modules that are
pure perl and don't have anything installed within
installarchlib by default. Fortunately MakeMaker
doesn't have any XS code, thus an upgrade rpm for
MakeMaker works fine without having to upgrade the
perl rpm itself. (I've already upgraded MakeMaker
on my box with an rpm just fine - no conflicts or
anything.) As explained in the README, just do:
cpan2rpm --shadow-pure --install ExtUtils::MakeMaker
This --shadow-pure is just a workaround hack until
perl fixes the default @INC ordering. Discussion:
I've hit this same problem with Net::Ping, another
module that is part of the perl core, of which I'm
the maintainer for.
> > FYI: To ensure it works on both the old and new versions of MakeMaker, the
> > following is used:
> > perl Makefile.PL
> > make
> > make install PREFIX=/foo/usr DESTDIR=/foo
> > (Yeah, I know, this still borks on 5.91 - 6.05.)
> > We cannot use the DESTDIR_CPAN2RPM method. I just hope that if the PREFIX
> > command is ever ported to be used on the new MakeMaker 6.x, that it won't
> > double up the prependages on the install.
If PREFIX ever starts working again from the
"make install" line, I guess I can just wipe the
DESTDIR part, and then everything will work
again. But until then, it seems to work okay.
> Have fun running into the new year!
Yes, HAPPY NEW YEAR TO ALL!