On Sat, May 31, 2008 at 4:41 AM, Raphael Hertzog [EMAIL PROTECTED] wrote:
On Fri, 30 May 2008, Andy Dougherty wrote:
On Sat, 31 May 2008, Brendan O'Dea wrote:
Not really. Adding a version into the path simply changes the failure
from an issue loading the .so (module is unusable) to one
On Mon, 02 Jun 2008, Brendan O'Dea wrote:
On Sat, May 31, 2008 at 4:41 AM, Raphael Hertzog [EMAIL PROTECTED] wrote:
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 {
[-doughera]
On Tue, Jun 3, 2008 at 12:11 AM, Raphael Hertzog [EMAIL PROTECTED] wrote:
On Mon, 02 Jun 2008, Brendan O'Dea wrote:
Modifying update-alternatives to set $ENV{PERL_DL_NONLAZY} would
appear to be the most appropriate solution here.
I tried this but it doesn't work. The variable
On Tue, 03 Jun 2008, Brendan O'Dea wrote:
I tried this but it doesn't work. The variable needs to be set before perl
is executed apparently. So you'd need some trick so that the script exec
itself a second time but with the environment variable set.
Really? Something like this fails?
On Fri, May 16, 2008 at 10:31 PM, Andy Dougherty [EMAIL PROTECTED] wrote:
On Thu, 15 May 2008, Niko Tyni wrote:
we're currently doing the 5.8.8 - 5.10.0 transition in Debian, and the
binary incompatibility in the XS module interface is biting us in an
unexpected way.
In a nutshell, it's
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:
we're currently doing the 5.8.8 - 5.10.0 transition in Debian, and the
binary incompatibility in the XS module interface is biting us in
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
2008/5/17 Niko Tyni [EMAIL PROTECTED]:
How about just documenting this a bit more with something like the
attached patch? I still think it's unexpected that 'eval require Foo'
isn't enough to trap the error.
Yes. Thanks, applied as change #33848.
Some clarifications:
- I'm not familiar
On Sun, 18 May 2008, Rafael Garcia-Suarez wrote:
- the circumstances where this shows up in the Debian context are
somewhat a corner case where 'preinst upgrade' scripts that need XS
modules may get run with a new XS module but the old perl. The
package dependencies are not yet
(cutting off P5P from the cc: list, since that's getting off topic)
2008/5/18 Raphael Hertzog [EMAIL PROTECTED]:
As a current maintainer of dpkg, I can tell you that dpkg2 has never been
anything else than vaporware. I know of nobody working on a dpkg rewrite.
Ah, pity, there was some
On Sat, May 17, 2008 at 12:02:31AM +0100, Nicholas Clark wrote:
Changing this doesn't feel right. I suspect that Gisle's reasoning is part of
my gut feeling on this. Lazy has been the default since 5.002 (1996), and
prior to that was the only option. I never remember this being a problem.
On Thu, 15 May 2008, Niko Tyni wrote:
Hi p5p,
we're currently doing the 5.8.8 - 5.10.0 transition in Debian, and the
binary incompatibility in the XS module interface is biting us in an
unexpected way.
In a nutshell, it's possible during the upgrade to temporarily end up
in a state
On Fri, May 16, 2008 at 03:04:21PM +0200, Rafael Garcia-Suarez wrote:
2008/5/16 Gisle Aas [EMAIL PROTECTED]:
Another objection is that you might simply want to load the module and use
some function that does resolve. Making require always fail if some
functions doesn't resolve prevent this
On Sat, May 17, 2008 at 12:02:31AM +0100, Nicholas Clark wrote:
Perl 5.6.x and Perl 5.8.x are not binary compatible either, yet Debian
upgraded from 5.6.x to 5.8.x without hitting this issue. What changed?
DynaLoader certainly didn't, hence why I'm highly suspicious that changing
it is not
Hi p5p,
we're currently doing the 5.8.8 - 5.10.0 transition in Debian, and the
binary incompatibility in the XS module interface is biting us in an
unexpected way.
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
15 matches
Mail list logo
