Re: Perl upgrade risks
On Wed, Jun 29, 2005 at 05:57:25PM -0700, Steve Lamb wrote:
> Almut Behrens wrote:
> > (2) Install the new perl 5.8.7 in /usr/local and leave 5.6.1 as it is.
> > This is probably the safest bet. In your software that needs >5.8.0,
> > make sure you're calling the new version
>
> This doesn't work to well with packages since the packages in question
> could contain a dependancy to the Perl 5.8 package. So it's now getting into
> a triple nasty hack.
>
> 1: get Perl 5.8 into /usr/local
> 2: trick any packages that depend on 5.8 that it is installed when it isn't.
> 3: Pay attention to those packages and manually fix them... every update... to
> point to the peron in /usr/local
>
> Nasty business, esp. point3, and extremely prone to failure.
yes, absolutely correct.
>
> Better way to do it is this. Yes, there can be problems when upgrading to
> a newer version of a dependancy (in this case, Perl). What you can do is
> install the old version in /usr/local, change all your custom scripts over to
> that version and then upgrade. If any system scripts have a problem with the
> upgrade that is buggable and should be handled by Debian. Custom scripts
> would still use the old version and you can then, one by one, run them against
> the newer version of perl. If they still work, remove the local. If they
> don't you can then debug without worry about not having said script for an
> extended period of time.
My impression was that the OP needs a _temporary_ solution for a single
perl program. In that case, I'm not entirely sure which way round
(5.8.x or 5.6.1 in /usr/local) would cause more work and problems.
Well, I guess both approaches have their pros and cons.
BTW, doesn't the perl from sarge require a newer libc than what is in
woody? -- which would typically open up another can of worms... (unless
you're building perl yourself, of course)
Almut
Reply to: