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.
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.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
signature.asc
Description: OpenPGP digital signature
