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

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

>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
>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
> Provides: perlabi-5.12.0-thread-multi-64int-ld

My inclination would be not to use something this verbose.  It implies
that there could be multiple concurrent builds, which was something I
spent some time and effort removing.

It seems to me that you could leave it as-is, for this release but
additionally make this policy change:

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

...which I think is rather a sound idea, which allows you in the ideal
case to retain a concise dependency, but does not preclude you changing it
arbitrarily should it turn out that there are issues with 64int+ld moving
forward.  In which case anything would suffice: perlapi-5.12.0-32int for
example if you were backing out the change.  This of course need not be
permanent, the next version could be just perlapi-5.12.1 again.

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

This should not even be required for this transition: no prior package
will meet the 64int+lb ABI.

>[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?

The name came from the variables in perl used to denote the oldest
compatible binary version: api_{revision,version,subversion}.


Feel free to s/abi/api/ if it truely bothers you.


Reply to: