Re: libclass-xsaccessor-perl: defining PERL_CORE for external XS modules and ABI stability
On Mon, Aug 16, 2010 at 11:59:33AM +0300, Damyan Ivanov wrote:
> -=| Ansgar Burchardt, Mon, Aug 16, 2010 at 01:50:23PM +0900 |=-
> > I wonder whether it is safe to keep this in Debian as the XS modules depend
> > on perlapi-*, or if this does not guarantee that (internal) offsets do
> > not change and we should not define PERL_CORE for the Debian
> > package.
>
> I think keeping this is safe. Perhaps even defining PERL_CORE globally
> would be safe. I guess the whle dance around perl internals is to
> allow the XS module to work with a perl binary with a different ABI --
> something we solve differently in Debian.
If I understand this correctly, upstream's promise of binary compatibility
between maintenance releases does not cover things hidden by PERL_CORE.
Therefore the perlapi-* dependencies may not ensure that things keep
working: a hypothetical 5.10.2 package could provide both perlapi-5.10.2
and perlapi-5.10.1 while reordering the underlying structs. All the well
behaved modules should be OK after all.
This means the safest way would be for those packages defining PERL_CORE
to explicitly depend on the current upstream version of Perl and require
binNMU rebuilds whenever that changes. This isn't particularly hard to do
[1], and would be even easier with #579112 resolved.
I think this applies equally to existing packages like
libapache2-mod-perl2 and speedy-cgi-perl too, and I think they are
currently somewhat buggy in this regard.
However, I agree this is most probably just a theoretical problem and is
not likely to occur in practice, at least in the near future. I don't
really think we will see 5.10.2, and the current rules for acceptable
changes in 5.12 maintenance releases are about as strict as we have for
Debian stable updates.
If things come to the worst and this actually breaks at some point, it
should be easy enough to fix. We'd just have to implement the postponed
'depend on the current Perl version' scheme in all the broken packages
and then put respective Breaks: entries in perl-base to keep partial
upgrades working.
So, do whatever you want :)
[1] see the libdevel-cover-perl package for an implementation
--
Niko Tyni ntyni@debian.org
Reply to: