-=| 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-p...@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.
signature.asc
Description: Digital signature
