Hi all, Damyan Ivanov wrote:
-=| Ansgar Burchardt, Mon, Aug 16, 2010 at 01:50:23PM +0900 |=-Hi, the last upstream release of libclass-xsaccessor-perl (1.07) contains this change:
Wow, you were quick to pick this up! The change in question is a (significant) optimization.
--- 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 Class::XSAccessor 1.07.
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 donot 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.
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.
Cheers, Steffen (one of the Class::XSAccessor guys)