Subject: Re: Pending perl changes
To: Geoff Wing <email@example.com>
From: Johnny C. Lam <jlam@NetBSD.org>
Date: 07/16/2005 02:05:57
On Sat, Jul 16, 2005 at 01:13:54AM +0000, Geoff Wing wrote:
> Johnny C. Lam <firstname.lastname@example.org> typed:
> : I'm going to be committing my massive Perl changes next week. I've
> : attached a diff of lang/perl5 for people that want to look it over
> : and test it.
> 1) Had 3 failed tests. Will reproduce if required.
2 of those errors are the result of pkgsrc modifications to MakeMaker
that prevent the automatic creation/update of perllocal.pod. The last
error is probably the sigaction one which has been around for a while,
at least on NetBSD.
> 2) Also, what's with
> Installing manpages to "/usr/pkg/lib/perl5/man":
> where previously they'd go to "/usr/pkg/man" (mail/mhonarc did this and failed
> on PLIST stuff)?
This avoids man page conflicts between standard Perl library modules,
3rd-party modules, and other packages. There is a script not present in
the diff I sent that manages symlinks into /usr/pkg/bin and /usr/pkg/man
for installed Perl modules so that they may be used without any changes
to your PATH, MANPATH, etc.
mail/mhonarc looks like it has on odd build/install system, and will
need to be modified to work correctly after these Perl changes are
> 3) mail/spamassasin is installing in
> where previously it would go in
> but PLIST is properly determined. This looks like a deliberate change to
> allow updating perl without updating the local packages that depend upon it,
> however this doesn't really make sense with our pkgsrc system (unless you
> force a perl update in place).
Yes, all pkgsrc-installed Perl modules will now be installed in the
"vendor" directories instead of the "site" directories. The "site"
directories can now be used by the local admin to install non-pkgsrc
Perl modules. The module search path precedence will be "site", then
"vendor", then "perl" locations.
After these changes, you will be able to re-use p5-* binary packages
with newer versions of Perl, provided the new Perl has the same API
version. This is a win because when you update the Perl package, you
will not need to rebuild everything that depended on the Perl package.
-- Johnny Lam <jlam@NetBSD.org>