Re: PERL5LIB behaviour in pkgsrc broken

[Steven Drake <sbd%NetBSD.org@localhost>]

On Wed, 24 Oct 2012, Thomas Klausner wrote:

> In usual perl installations, setting PERL5LIB to /path/to/lib/perl5 is
> sufficient, because the subdirectories for version and architecture
> are automatically searched. I.e. adding /path/to/lib/perl5
> automatically searches /path/to/lib/perl5/5.16.1 and
> /path/to/lib/perl5/5.16.1/x86_64-netbsd-thread-multi.
> 
> This breaks for perl modules installed outside of pkgsrc by perl from
> pkgsrc, since they are installed into /path/to/lib/perl5/5.16.0
> (previously, 5.14.0) even if the version is 5.16.1 (or 5.14.2,
> before). For perl-5.16.1 you need to change PERL5LIB to point to
> /path/to/lib/perl5/5.16.0 manually (the architecture support works;
> i.e., /path/to/lib/perl5/5.16.0/x86_64-netbsd-thread-multi is added
> automatically).

How is this a problem?

If you build a perl module outside of pkgsrc with pkgsrc's perl the modules
get install to /path/to/lib/perl5/site_perl/5.16.0 and thats where pkgsrc's
perl looks for modules.

> I'd like to know:
> 
> 1. Why it was done? (My guess is that someone decided perl 5.x.y and
> 5.x.z would always be compatible)

The version number used in the path is the perl API version from
patchlevel.h and I would guess its so that when perl is updated with a
maintenance release (i.e. 5.x.y to 5.x.z) a recursive revbump isn't needed,
(as apposed to upgrading 5.x to 5.y which does).

> 2. How this is changed in pkgsrc (to install to .0 instead of the real
> version) -- which patch or Makefile fragment does that?

The paths are set in Policy.sh from values in dirs.mk which uses the
PERL_API_* values from patchlevel.h.

> 3. If we should revert that, or adapt the path searching strategy perl
> uses by default to look in *.0 as well. If you know where this is done
> in perl, please tell us.

For the reason given in my answer to  question #1 I think it should
definably not be reverted.

-- 
Steven