Subject: Re: Pending perl changes
To: Todd Vierling <tv@duh.org>
From: Johnny C. Lam <jlam@NetBSD.org>
List: tech-pkg
Date: 07/16/2005 22:02:02
On Sat, Jul 16, 2005 at 05:25:27PM -0400, Todd Vierling wrote:
> On Sat, 16 Jul 2005, Johnny C. Lam wrote:
> 
> > What would normally be installed into /usr/pkg/bin (the "script"
> > directory for a perl module) is now installed into
> > /usr/pkg/lib/perl5/vendor_perl/bin and then symlinked over into /usr/pkg/bin.
> 
> So long as this does not require special pkgsrc buttressing (i.e., perl
> still installs into PREFIX/bin if I use CPAN directly), then it's OK.
> 
> It must be possible to build CPAN or MakeMaker based applications in
> general, directly (not via pkgsrc), and get them installed to PREFIX/bin
> like all other Perl applications.  Sure, it would be best if everything were
> in pkgsrc, but it is not always the case, and Perl should act like ... Perl.

I disagree.  Perl allows for nearly infinite flexibility in the choice
of install locations, and it's up to the Perl vendor to choose defaults
for the particular platform of interest.  In this case, the default
location for Perl scripts is one of the following, depending on where
you ask for the Perl module to be installed:

	/usr/pkg/lib/perl5/bin (perl)
	/usr/pkg/lib/perl5/site_perl/bin (site)
	/usr/pkg/lib/perl5/vendor_perl/bin (vendor)

pkgsrc-installed modules will have a POST-INSTALL action that symlinks
the scripts for that module into /usr/pkg/bin.  If you blindly use
CPAN, odds are that you'll install into the "site" directories.  The
user must manually run the appropriate command to symlink scripts into
/usr/pkg/bin, which frankly, I discourage because I don't want
non-pkgsrc-managed things to end up under /usr/pkg.

I'm going to rework the perl package a bit to allow for choosing a
different "siteprefix" at build-time that would let the user install
site-bits into a separate hierarchy that's completely unmanaged by
pkgsrc, and in that case, allow the normal defaults to be used.  In this
case, if the "siteprefix" is set to be /usr/local, then "site" Perl modules
will be installed into:

	/usr/local/bin
	/usr/local/lib/perl5/site_perl/5.8.7
	/usr/local/lib/perl5/site_perl/5.8.7/i386-netbsd-thread-multi
	/usr/local/man/man1
	/usr/local/man/man3

But if the user insists on using the pkgsrc default for "siteprefix",
which is /usr/pkg, then I will insist that "site" modules not ever
conflict with or overwrite things that pkgsrc installs.

> > This allows installing perl modules that are also in the base perl
> > distribution but that would also install scripts that, before these changes,
> > would conflict with perl's own scripts, but would now simply be replaced via
> > symlink instead.
> 
> We have a need to update base Perl scripts?  .pm's are easy to override by
> virtue of @INC being properly ordered, but what base install scripts need
> this special handling?

In the past, we've modified some p5-* modules to not install their
scripts because they conflicted with the perl package's own scripts.
This arose because the p5-* modules were newer versions of some modules
provided the perl package which happened to install scripts.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>