[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

Re: Finding old library directories (was Re: automatic perl modulerpm wrapper)



On Tue, 11 Jan 2000, Nick Ing-Simmons wrote:

> Andy Dougherty <doughera@lafayette.edu> writes:
> >On Mon, 10 Jan 2000, Nick Ing-Simmons wrote:
> >
> >> I was suggesting hunting $ENV{PATH} for "current" perl(s)
> >
> >No, I don't think so.  If I have "current" perl in /opt/perl5.005/ and I'm
> >installing the "new" perl in /opt/perl5.6.0 in order to keep separate
> >versions separate, then I don't think the default installation of
> >perl5.6.0 ought to go hunting in /opt/perl5.005 for its sitelib
> >directories.  This isn't keeping separate things separate.
> 
> I could not agree more - all my work perls are like that.
> But that is making the case for NOT adding "existing site lib" to the 
> @INC path. 
> 
> The subject under discussion is HOW to add "existing site lib"
> to the @INC path - once "we" have decided to make this an option we can 
> decide how best to find the libs. It seems to me that if a person
> wants to keep the site lib stuff visible, then it is presumably the 
> perl they are using _now_ that they want to re-use i.e. the perl that is 
> found by $PATH search.

My plan is simpler.  If the user deliberately separates different
versions, then I don't think the default ought to fiddle with that.

If the user simply accepts the default installation structure, and
installs 5.005, 5.6, 5.7, 5.8, . . . all to the same $prefix, then I think
we ought to try to make the upgrade process as smooth as is reasonable.
Such a user will have a sitelib that looks like (assuming
prefix=/usr/local)

	$ ls /usr/local/lib/perl5/site_perl
	5.005/  5.6.0/  5.6.1/  5.7.0/  5.7.1/  5.8.0/   [...]

My proposal is that (for example) 5.6.1 also will look back in 5.6.0 and
5.005's directories.  This will allow somewhat less painful upgrades but
not interfere with most of those who have other version control
strategies. I am not proposing we go aggressively looking elsewhere on the
system for where other versions of perl may be installed.  I think that
will cause more problems than it will solve.

    Andy Dougherty		doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042


Follow-Ups from:
Gurusamy Sarathy <gsar@ActiveState.com>
References to:
Nick Ing-Simmons <nik@tiuk.ti.com>

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]