On Fri, 30 May 2008, Andy Dougherty wrote:
> On Sat, 31 May 2008, Brendan O'Dea wrote:
> > On Fri, May 16, 2008 at 10:31 PM, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > > On Thu, 15 May 2008, Niko Tyni wrote:
> > >> In a nutshell, it's possible during the upgrade to temporarily end up
> > >> in a state where perl is still 5.8.8, but some XS modules are already
> > >> the new ones (ie. built for 5.10.0).
>
> > > Changing 5.10.0's $Config{vendorarch} to include the string "5.10" (much
> > > as is done for $Config{archlib} aleady) might solve this problem. Or at
> > > least it might cause the failure to appear earlier and in a way that is
> > > easier to trap gracefully.
> >
> > Not really. Adding a version into the path simply changes the failure
> > from an issue loading the .so (module is unusable) to one where the
> > module is not found at all (module is unusable).
>
> Agreed. In neither case does it actually work.
That's wrong. The "use Locale::Gettext" is protected by eval {} and
update-alternatives works well when the eval fails... as it subsitutes
gettext() with a simple sub return { [EMAIL PROTECTED] }.
So if the module is missing, update-alternatives works.
If the module is for the wrong perl version, then the problem is not catched
by eval {} due to the lazy symbol loading and the script is killed as soon
as it tries to use a symbol from the library.
That's why the initial request was to disable lazy symbol loading inside
eval.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
