Re: pkg/29404

[jlam%netbsd.org@localhost]

Synopsis: perl modules not seen by updated perl

State-Changed-From-To: open->analyzed
State-Changed-By: jlam%netbsd.org@localhost
State-Changed-When: Wed, 08 Jun 2005 00:07:43 +0000
State-Changed-Why:
This PR is marked as analyzed and will be handled after the pkgsrc-2005Q2
branch is cut.

I believe the approach suggested in this PR is incorrect, although
the problem certainly exists.  There are ABI differences between
different versions of libperl.so which are not captured in the shared
library name, but which still need to be enforced.  Basically, you
need to have a perl of an equivalent ABI, which typically means one
from the 5.8.x branch if you're a perl-5.8.x user, or from the 5.6.x
branch if you're a perl-5.6.x user.

After the pkgsrc-2005Q2 branch, perl will be restructured to install
all pkgsrc perl modules into the "vendor" directories, which will be
moved ahead of the "standard" perl library directories in precedence.
In addition, Perl will be configured so that the "version" used for
the Perl subdirectories matches the Perl API number, which is the
one listed in patchlevel.h, e.g., for perl-5.8.6, patchlevel.h gives:

#define PERL_API_REVISION       5  /* Adjust manually as needed.  */
#define PERL_API_VERSION        8  /* Adjust manually as needed.  */
#define PERL_API_SUBVERSION     0  /* Adjust manually as needed.  */

Thus, a perl module that's built against perl-5.8.6 would have a
PERL_API=5.8.0 and would install into

/usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd/MIME/Base64.pm
/usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd/auto/MIME/Base64.bs
/usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd/auto/MIME/Base64.so

Also, libperl.so would be found as:

/usr/pkg/lib/perl5/5.8.0/ie86-netbsd/CORE/libperl.so

These files, even if provided by a binary package, would continue to
be found after the perl package has been updated to perl-5.8.7.

Dependencies for perl modules should be expressed as:

        perl>=${PERL_API}

In this way, modules will always require a Perl that presents the same
API, and they won't be install if you only have an older perl on the
system.

I believe that Debian gets it wrong and that it's important to preserve
the version numbers in the directory names because libperl.so is
unversioned, and there's no other real defense against linking against
the wrong shared library otherwise.