develooper Front page | perl.perl5.porters | Postings from April 2003

Re: OS X's vendorlib default seems wrong

Thread Previous | Thread Next
From:
Michael G Schwern
Date:
April 6, 2003 15:24
Subject:
Re: OS X's vendorlib default seems wrong
Message ID:
20030406221837.GC6015@windhund.schwern.org
On Sun, Apr 06, 2003 at 02:24:47PM -0700, Wilfredo Sánchez wrote:
>   Yeah, bad hack perhaps.  But we do want to search 
> /Network/Library/Perl.  

There is a better way to add extra things to @INC (if not, I'll make one).  
Try setting otherlibdirs instead.


> Even today, I don't really understand what 
> vendorlib is, as opposed to sitelib.

There's three main install targets for Perl.  Core, site and vendor.

Core (prefix, privlib, archlib) is for stuff that comes with Perl itself.

Site (siteprefix, sitelib, sitearch) is for things installed by the user
from CPAN and other misc locations.

Vendor (vendorprefix, vendorlib, vendorarch) is for things installed by the
OS vendor and maintained by the OS vendor.  For example, Debian packages,
Redhat packages, fink packages, Apple supplied modules, etc...


Site and Vendor are seperate in order to keep official, vendor supplied
libraries seperate from stuff the user just happened to install.  This is
important for many reasons, the one I'm most familiar with is when the
vendor supplied libraries are part of a packaging system.  Consider this
scenario:

Debian user installs Perl.  Debian user installs the libfoo-bar-perl package
which contains Foo::Bar 1.0.  Debian user then fires up CPAN and installs
the latest version, 1.6.  Later, he runs a Debian upgrade.  A new version
of libfoo-bar-perl is installed, but its only up to 1.1.

If everything is going into siteperl, he just downgraded from 1.6. to 1.1.
Bad.

But if the libfoo-bar-perl package installs into vendorlib and CPAN installs
into sitelib, and if sitelib comes before vendorlib in @INC, then the CPAN
version continues to override the version in libfoo-bar-perl.  

Seperating vendor from site allows a way for a user of vendor supplied perl
modules to safely override them without danger of being downgraded by the
vendor (since the vendor almost always lags behind CPAN).


The Debian Perl Policy explains this pretty well and and its the best Perl
installation policy I've seen yet.  Follow their lead.
http://www.debian.org/doc/packaging-manuals/perl-policy/


-- 
Free beer w/riot!

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About