Subject: Re: And speaking of PKGREVISION: Perl version bumping
To: Jeremy C. Reed <>
From: Greg A. Woods <>
List: tech-pkg
Date: 01/10/2005 13:57:42
[ On Wednesday, January 5, 2005 at 15:09:35 (-0800), Jeremy C. Reed wrote: ]
> Subject: Re: And speaking of PKGREVISION: Perl version bumping
> On Wed, 5 Jan 2005, Todd Vierling wrote:
> > So I ran into something today that was rather ... interesting.  We still
> > have an issue with Perl, insofar that modules containing .so's cannot load
> > any longer when the Perl package is updated.  I had modules compiled against
> > 5.8.5, and when updating to 5.8.6, the existing binpkgs could no longer find
> > (because the rpath was now wrong).
> I wonder if a symlink could be used for 5.8 and set the RPATH to use it
> instead. I don't know if that is safe for all of these perl modules
> though.

I think the right thing to do would be to do it in the same way that
lang/ruby* is now set up to do (which is how all these things should
have been done in the first place of course).

However I don't know if it's as easy to set up all installed perl
scripts to directly invoke the correct version-specific perl

I.e. it should be possible to have any number of versions of any
interpreter installed at any time and the scripts that use them should
directly invoke the correct version, which should then result in the
correct runtime load modules being found too.

The plain un-suffixed $PREFIX/bin/perl file (symlink) should be managed
by a separate package and should only ever be used directly by humans
who just want to invoke the default perl interpreter when they're not
running some specific installed perl script.

The same control logic used in lang/perl to select the default
interpreter version to symlink to would also be used to select the
specific interpreter to be used by "portable" script packages that are
compatible with many interpreter versions.

						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <>
Planix, Inc. <>          Secrets of the Weird <>