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

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



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]

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.

-- 
Niko Tyni   ntyni@debian.org



Reply to: