[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#2182: perl shouldn't touch /usr/local



> In message <[🔎] 199601190632.BAA24180@deimos.mars.org>, Robert Leslie writes:
> 
>> Perl creates a directory /usr/local/lib/site_perl/i486-linux, but FSSTND
>> says, about /usr/local:
>>   [...]
>>   This directory should always be empty after first installing Linux.  No
>>   exceptions to this rule should be made other than the listed directory
>>   stubs.
>>   [...]
> 
> Where, then, would the FSSSTND have me put CGI.pm (a piece of Perl
> code that is not part of the standard perl distribution, likely never
> will be, yet I need on just about every system I work with)?

I personally don't care where you put it, but it *would* make sense for you to
put it somewhere in /usr/local. Doing this is *your* decision, though; it
shouldn't be the decision of the perl package.

I feel very strongly against the base system mucking with anything in
/usr/local -- this is by definition *my* playground, and mine alone as system
administrator of my machine. The system should not be preconfigured to depend
on anything inside it apart from the directory stubs listed in FSSTND.

> Is it really the opinion of the FSSTND group that it is better for me
> to have to hack a script to examine @INC than for the distribution to
> go to the trouble of pointing out where I can put local extensions so
> they will be treated in a sensible fashion?

I don't think setting your PERL5LIB environment variable to include
/usr/local/lib/site_perl (or whatever directory suits you) is asking too
much.

> If the answer is yes, then we shouldn't pay terribly slavish attention
> to something that is so obviously inconsiderate of the needs of real
> users.

Having perl preconfigured to look in /usr/local/lib/site_perl for local
extensions may be convenient (for you), but it is really wrong for the perl
package to be imposing structure /usr/local, not to mention *depend* on any of
its contents for normal operation.

-- 
Robert Leslie
rob@mars.org


Reply to: