On Sat, Jul 16, 2005 at 01:13:54AM +0000, Geoff Wing wrote:
> Johnny C. Lam <jlam@netbsd.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
committed.

> 3) mail/spamassasin is installing in
>   /usr/pkg/lib/perl5/vendor_perl/5.8.0/
> where previously it would go in 
>   /usr/pkg/lib/perl5/site_perl/5.8.6/
> 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.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>