-=| Niko Tyni, Tue, Apr 27, 2010 at 10:55:54PM +0300 |=-
> Package: debian-policy
> Version: 3.8.4.0
> Severity: wishlist
> X-Debbugs-Cc: debian-perl@lists.debian.org
>
> The Perl policy currently mandates that the perl-base package provides
> perlapi-<version> for every upstream version it is binary compatible
> with. XS modules are required to depend on this so that there's a
> transition path when Perl version upgrades include incompatible ABI
> changes [1].
>
> However, the binary interface is also affected by several configuration
> settings chosen at Perl build time. These include support for
> threading (usethreads), 64-bit integers (use64bitint) and long doubles
> (uselongdouble).
>
> I would like to include these settings in the virtual package name so
> that it would be possible to make incompatible ABI changes during the
> life time of a single Perl upstream version and have a clean transition
> path.
>
> Obviously this does not mean that the ABI would be changed lightly,
> it only makes it possible when really required. [2]
Sounds good to me.
> As for the implementation, the name of the virtual package could be
> derived from $Config{archname}, for example x86_64-linux-gnu-thread-multi.
> The system type prefix seems unnecessary; stripping it out and adding
> the version number would give something like
> Provides: perlabi-5.10.1-thread-multi, perlabi-5.10.0-thread-multi
> or
> Provides: perlabi-5.12.0-thread-multi-64int-ld
>
> For convenience, the perl package could include the suffix and/or the
> whole string in something like $Config{debian_abi}. In that case we
> should probably mandate that packages need to use it rather than derive
> the string themselves.
+1
> The transition from the current perlapi-* scheme does not seem
> difficult:
> affected packages can be easily found and changing dh_perl in debhelper
> would be the only required source fix for a vast majority of them.
>
> The perl-base package could provide both the old perlapi-<version>
> and the new perlabi-<version>-<suffix> during the transition period and
> remove the perlapi-* one when all the packages have been changed.
+1
> I'm copying the debian-perl list to reach any interested parties.
> If there's a consensus that this looks sane and useful, I could make the
> required changes in the perl package easily and then try to come up with
> a proposed wording for the policy change.
>
> Please comment.
>
> [1] Given that this is all about binary compatibility, I don't understand
> why the virtual package is called perlapi-* and not perlabi-*.
> Maybe somebody could enlighten me?
>
> [2] The particular use case I have in mind is enabling uselongdouble
> or use64bitint for Perl 5.12.0 in sid and later finding out that it
> was the wrong thing to do for some unanticipated reason. Currently
> there is no way to change these settings cleanly before the next
> upstream version comes around.
>
> Obviously I'm doing my best to test the choices in experimental first,
> but surprises can still happen and I'd like a last resort way
> out.
Seems a valid reason to me.
Attachment:
signature.asc
Description: Digital signature