On Thu, Jun 22, 2006 at 10:18:10PM -0500, Ken Williams wrote: > > On Jun 20, 2006, at 2:29 AM, Yitzchak Scott-Thoennes wrote: > >On Tue, Jun 20, 2006 at 08:07:45AM +0200, demerphq wrote: > >>On 6/20/06, Yitzchak Scott-Thoennes <[EMAIL PROTECTED]> wrote: > >>>If so, that's a bug in Data-Dumper; dual-lived modules should set > >>>installdir to perl if being installed for a perl version on which > >>>they are in the core. > >> > >>I dont really agree. If an module is found in site/lib then I know > >>that its been installed locally. When its a "core" module then i know > >>that the "approved" release version from that perl has been changed. > >>Which is useful information. > > > >Then you would specify INSTALLDIRS=site. Most packaging systems would > >also want to do so (or use =vendor). But the default is supposed to > >be updating the core-supplied version. > > Actually, that's the way one *must* do it. If a module is installed > as part of the core, then installing another version to 'site' > generally won't have any effect because the core dirs come first in > @INC.
With UNINST=1, order becomes irrelevant, but that obviously isn't a good solution for a packaging system. IIRC, some vendor perls have the @INC order tweaked to put site first for this reason.
