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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
