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 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).
>
> The default perl installation was deliberately designed to avoid just this
> problem by including a version-specific directory-path in
> $Config{vendorarch}. That way perl-5.8.8 would not try to load
> incompatible perl-5.10.0 modules. Debian's build script deliberately does
> not include a version-specific $Config{vendorarch}. It might be worth
> reviewing that decision.
I chose many releases ago (5.6.0) not to include a version in the
vendor path, since the packaging system is capable of ensuring that
the packages in those directories are correct for the current perl
version (more detail in the Debian Perl Policy). This has worked
pretty well.
One issue which should be highlighted is that no such guarantees are
made *during* the upgrade process. In fact Debian policy is pretty
explicit as to what is valid for maintainer scripts to invoke: either
the package providing the binary must be flagged as "Essential" (in
which case there are additional requirements placed on the package
such that it is functional even when not configured) or a
Pre-Dependency must be declared (ensuring that dpkg with not only
unpack, but will configure said dependency package before attempting
to configure the dependant).
So... after that legalese the actual problem in this case is that dpkg
(an Essential program) has a component: update-alternatives which is
not functioning when un-configured. Bad. But a problem with dpkg,
not perl.
> 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).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
