Re: libclass-xsaccessor-perl: defining PERL_CORE for external XS modules and ABI stability
Damyan Ivanov wrote:
-=| Ansgar Burchardt, Mon, Aug 16, 2010 at 01:50:23PM +0900 |=-
the last upstream release of libclass-xsaccessor-perl (1.07) contains
Wow, you were quick to pick this up! The change in question is a
--- XSAccessor.xs (revision 61639)
+++ XSAccessor.xs (working copy)
+ * defining PERL_CORE gets us the fast version, at the expense of a future maintenance release
+ * possibly breaking things: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-04/msg00171.html
This is the important bit wrt. maintenance. It means that if I'm using
any of the Perl internals, and they're changed in a future release, I
get to keep all parts as a maintainer and get the wraith of the other
perl5-porters as an extra benefit.
Effectively, we're not really making use of a lot of internals things.
Additionally, since C::XSAccessor is fairly widely used and I track the
core perl development, it's unlikely to be broken by a future *released*
version of perl. Therefore, the worst case for you is that you'll have
to repackage a future (fixed) version of Class::XSAccessor when you
upgrade perl *and* that particular version of perl broke
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
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.
I agree that it should be safe. Besides. I'm sure there's plenty of
other CPAN modules packaged in debian that (similarly illegally) define
PERL_CORE. I'd bet that quite a few modules even cargo-culted a "#define
PERL_CORE" without needing it at all.
Steffen (one of the Class::XSAccessor guys)