Mailing List Archive

>>>>> "Nick" == Nick Ing-Simmons <nik@tiuk.ti.com> writes:

Nick> Someone else has re-discovered that 'sitelib' is searched first.
Nick> I think this is a mistake. The place(s) that *this* version
Nick> installs things should be what is looked for first, then use
Nick> sitelib for fallback.

For the reasons Nick and others have listed, sitelib last is a
requirement here as well. I've hacked perl.c to do this for out
version, but it seems the Right Thing would be a configurable option.

I do beleive the default should be the opposie of what is currently
does.

Phil

Nick Ing-Simmons writes:
>
> Someone else has re-discovered that 'sitelib' is searched first.
> I think this is a mistake. The place(s) that *this* version installs
> things should be what is looked for first, then use sitelib for fallback.
>

Hmm, looks perfectly fine for me. Sitelib is (AFAIU) used to install
the additional site-specific extensions, which may in particular
override "old" distribution modules. Thus it should be first on the
search path. Do I miss something?

Ilya

> Sitelib is (AFAIU) used to install
> the additional site-specific extensions, which may in particular
> override "old" distribution modules. Thus it should be first on the
> search path. Do I miss something?

Yes,
- an extension to an old perl may become part of a later perl version.

- a modified perl module may not work at all with another perl version
(it might "know" too much about perl internals, or the newer perl
might depend on newer parts of the module).

OTOH, it would be a pity to be unable to override standard modules.

All right, how about this search path:

$sitelib/$version
/usr/lib/perl/$version/
$sitelib/

You put overrides in $sitelib/$version, and normal extensions in $sitelib/.
(And of course, we might want an $arch/ subdir inside each of the dirs above.)


Regards,

Hallvard

Hallvard B Furuseth writes:
> All right, how about this search path:
>
> $sitelib/$version
> /usr/lib/perl/$version/
> $sitelib/
>
If you guys are so serious, I take out my objection. I _want_
installed extensions to survive perl upgrade. But if I force PREFIX
into MakeMaker, I may always use it, and site-wide PERL5LIB.

Ilya

In <199511062102.QAA10005@monk.mps.ohio-state.edu>
On Mon, 6 Nov 1995 16:02:07 -0500 (EST)
Ilya Zakharevich <ilya@math.ohio-state.edu> writes:
>Nick Ing-Simmons writes:
>>
>> Someone else has re-discovered that 'sitelib' is searched first.
>> I think this is a mistake. The place(s) that *this* version installs
>> things should be what is looked for first, then use sitelib for fallback.
>>
>
>Hmm, looks perfectly fine for me. Sitelib is (AFAIU) used to install
>the additional site-specific extensions, which may in particular
>override "old" distribution modules. Thus it should be first on the
>search path. Do I miss something?
>
It depends how you use it.

I was trying to use 'sitelib' to point to
/usr/local/lib/perl5 and installing perl5.001x to /usr/local/lib/perl5.001x,
all CPAN modules etc. went in sitelib. When a new version of perl or
a new module comes along I want to install that, and see how it coexists
with the existing 'site' install. i.e. does it break anything.
Thus I want it to search its own stuff first, but still have access to all
the other CPAN modules we use without re-installing them.
When proven not to break production scripts new perl or module is
re-installed into sitelib.

Thus I want to use sitelib as the 'stable' 'released' area.

Our approach to overriding old stuff is to do 'use lib newdir'.

As it stands so called 'sitelib' can be used as the 'alpha' location, but
the various 'installs' don't install into this 'alpha' but rather overwrite
'production' directory.

In <199511062247.XAA21469@durin.uio.no>
On Mon, 6 Nov 1995 23:47:35 +0100
Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:
>
> $sitelib/$version
> /usr/lib/perl/$version/
> $sitelib/
>
>You put overrides in $sitelib/$version, and normal extensions in $sitelib/.
>(And of course, we might want an $arch/ subdir inside each of the dirs above.)
>
Looks okay to me.

The confusion caused by sitelib suggests that it needs a better name.

Tim.