develooper Front page | perl.perl5.porters | Postings from January 2003

RE: MakeMaker problems with relocation

From:
Erick Calder
Date:
January 7, 2003 02:36
Subject:
RE: MakeMaker problems with relocation
Message ID:
000f01c2b4fd$44da06a0$8100a8c0@arix.com
> I picked the latest rawhide perl release and split off the
> MakeMaker bits into perl-ExtUtils-MakeMaker as a seperate rpm

hmm... I'm thinking to repackage perl itself as RH provides their RPM
without large-file support compiled in... grrr...

I wonder whether the perl team (us actually) could take on the
responsibility of packaging perl for RH so we don't have to dance around RH
decisions...?

-----Original Message-----
From: Axel Thimm [mailto:Axel.Thimm@physik.fu-berlin.de]
Sent: Saturday, January 04, 2003 10:59 AM
To: Michael G Schwern
Cc: Rob Brown; Erick Calder; Hugo van der Sanden; Perl 5 Porters; Rob
Brown
Subject: Re: MakeMaker problems with relocation


On Wed, Jan 01, 2003 at 02:11:00PM -0800, Michael G Schwern wrote:
> 6.06 is not ready to be rolled into Perl yet.  The Unix parts are ok, but
> the Win32, VMS and MacPerl bits are borked.  This likely doesn't matter to
> Redhat and they should be safe using the 6.06 alpha in their devel version
> (Rawhide?)

I picked the latest rawhide perl release and split off the MakeMaker bits
into
perl-ExtUtils-MakeMaker as a seperate rpm. This makes that part separately
replacable (same trick is used for other parts of perl like perl-CGI). You
can
get it from http://atrpms.physik.fu-berlin.de/repository/perl/ (binary rpms
are provided for RH80).

I was about to package a snapshot of 6.06 alpha to continue the testdrive,
but
I cannot download http://makemaker.org/src/ExtUtils-MakeMaker-snap.tgz for
some days now.

> That's all been thrown out.  The new logic is much simpler and does not
try
> to second-guess.
>
> With this in mind, you probably want to do something like this:
>
>      require ExtUtils::MakeMaker;
>      if( $ExtUtils::MakeMaker::VERSION <= 5.45 ) {
>      	 perl Makefile.PL
> 	 make
> 	 make install PREFIX=$RPM_TMP_ROOT/usr
>      }
>      elsif( $ExtUtils::MakeMaker::VERSION >= 6.06 ) {
>      	 perl Makefile.PL
> 	 make
> 	 make install DESTDIR=$RPM_TMP_ROOT
>      }
>      else {
>      	 unsupported version of MakeMaker, please upgrade.
>      }

I think these checks should be done at rpm-build time (in the spec file),
and
not at src.rpm-build time. Unfortunately rpm conditionals for requirements
do
only allow for ANDing conditions, not for ORing, which makes it even more
messy ... :(

How about the following hardliner suggestion:

a) src.rpms should always require MakeMaker's version to be larger than 6.05
   (e.g. 6.06, when it is about to be released or something like 6.05.99 for
   indicating the beta version):
   BuildRequires: perl(ExtUtils::MakeMaker) > 6.05
b) We use the method that is currently supported:
   perl Makefile.PL PREFIX=bar [...] make install PREFIX=foo
   as this seems to be the most forward-compatible and user comprehensive
way
   to go.
c) We provide modified perl and perl-ExtUtils-MakeMaker rpms (like the
above)
   until the vendors catch up.
--
Axel.Thimm@physik.fu-berlin.de




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About