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