On Thursday, August 15, 2002, at 03:53 PM, drieux wrote:
>
> On Thursday, August 15, 2002, at 06:21 , Kee Hinckley wrote:
> [..]
>> Of course this kind of solution is inherently dangerous given that
>> /usr/bin/perl and /usr/local/bin/perl may be different versions for
>> good reasons, and letting the interpreter executed depend on a user's
>> path can get you in trouble.
>
> I can understand why 'developers' will want to have
> 'multiple instances of perl' floating around on
> their machine - and one way would be to do this
> with the split between the prefix /usr/local and /usr.
>
> { I would argue against such a strategy - and advocate
> the older path of /usr/unsupported - IF one needs to
> have a 'commonly shared' 'development environment'. }
As 'developers' are a degenerated bunch of animals, they normally
keep their pack close to them.
What I mean is: their home directory.
> but I am not at all sure that this is a reasonable
> approach of 'production servers/hosts' - where the
> 'currently supported releases' should 'just work'
> for 'the user community'.
>
> As such, keeping /usr/bin/perl and /usr/local/bin/perl
> as the same - either by hard link or symbolic link -
> would save a lot of heartache for users and the IT staff.
Development should not interfere with any production environment
at all.
!But!: why should there be a development environment on a
*production* server?
You don't develop on *production* servers, that's what development
systems are for.
I for my part wouldn't sport any development software on production
hosts, without being sure that 'users' (programmers?) can cope
with pathnames ;-)
Kay
