On Thursday, August 15, 2002, at 11:53 PM, drieux wrote:
> 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'. }
>
> 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'.It's quite reasonable to have multiple versions of perl in a production environment, even though it may be a pain in the ass. The main reason is for forward transition and backward compatibility. If you've got 100 applications on a server, chances are some of them are going to break when you upgrade perl (more precisely, when the included modules change). So the safest sane way to transition forward to new versions of perl is to make sure that you keep the old & new versions separate, so that applications can choose which one they're using, and then "go live" with the updated versions when they've been properly updated & tested in development. The alternative is to do all the testing & development in advance on a development machine for all 100 applications so you can upgrade them all at the same time, when you install the new perl and blow away the old perl. And this doesn't give you an easy way out if some application starts having unforeseen problems, short of rolling back the entire upgrade. > > 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. Certainly true, but sometimes people make decisions that they deem are necessary but that they know will also give them heartache. -Ken
