On Thu, 26 Jul 2001 19:22:51 -0700, Chris Nandor wrote:
>It discusses these things
>in its README. It notes that you need to put site_perl in first if you
>want to override the defaults in lib.
Makes sense.
>I am not prepared to change the perl
>default (which is to have site_perl come *after* the main lib directory),
>but I might consider it.
Er... what? You're not prepared to do it, but you might consider it
anyway?
Since, in order for cpan-mac to work properly, you HAVE to put site_perl
first. Yet, in the default, it's not that way.
So now there are two defaults, depending on whether you have cpan-mac
installed, or not. That doesn't make sense. I think it's better to have
just one default, the one that works best. And what might that be? Well:
if you install a new version of a module, it should be used instead of
the old one. That's the reason behind the demand for cpan-mac, anyway.
So that seems best to me.
>The way it is done on Unix is to delete the
>installed version when you update in site_perl (as an option to CPAN.pm,
>otherwise make install warns you). Maybe we should just start recommending
>that.
That is rather drastic. If the new install doesn't work, you've just
lost your old install as well.
Putting site_perl in @INC first has the same effect, but without that
drastic, irreversible result.
p.s. If you install a new version of a module over an old version in
site_perl, and it doesn't work, than you still have lost the old
install. Oops.
At least, you had succeeded in installing the old module, or it wouldn't
have gotten into site_perl in the first place. So, if you have a copy of
the old archive, you can install it again.
p.p.s. if the default is to delete the old module, there's noreason to
put new modules into a different file tree, anyway.
--
Bart.
