On 6/20/06, Yitzchak Scott-Thoennes <[EMAIL PROTECTED]> wrote:
On Mon, Jun 19, 2006 at 02:32:10PM +0200, demerphq wrote:
> On 6/19/06, Ron Savage <[EMAIL PROTECTED]> wrote:
> >On Sun, 18 Jun 2006 22:02:16 -0500, Ken Williams wrote:
> >
> >Hi Ken
> >
> >>> When Module::Build is a core module will it still live in /perl/
> >>> site/lib/Module/ or will it move to /perl/lib/Module/?
> >>>
> >>
> >> You're talking about under Win32, right? I believe it will live in
> >
> >Yes, in this case, Windows.
> >
> >> / perl/lib/Module, along with all the other core modules.
> >
> >That's what I'd assumed.
> >
> >> M::B isn't planned to be core for any perl 5.8.x version, though.
> >> It's in 5.9.x now, which is blead for 5.10.
> >
> >Sure.
> >
> >> Maybe there's some general UNINST-like mechanism for eliminating
> >> duplicate modules in people's installations when some CPAN module
> >> goes core? I've never heard of this problem, nor its assumed
> >> solution, before, though.
> >
> >I guess if it comes pre-installed in a new Perl, it'll always be in
> >/perl/lib/Module, and never install itself into /perl/site/lib/Module, so
> >the
> >question is moot, right (he said hopefully)?
>
> Nope. If you upgrade it should go in to site/lib, meaning you have to
> use UNINST=1 if you upgrade.
>
> At least thats what happens with things like Data::Dumper
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.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
