[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#579457: debian-policy: finer granularity for perlapi-*

-=| Niko Tyni, Tue, Apr 27, 2010 at 10:55:54PM +0300 |=-
> Package: debian-policy
> Version:
> 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.


> 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.


> 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

Reply to: