Having $Config{vendorarch} change between Perl major versions (for
multiarch or other reasons) implies that packages using it need a strict
dependency on those versions of perl-base that have a compatible search
path (@INC).
The vast majority of these packages are binary ("XS") modules, where we
already require a dependency on the virtual package perlapi-*, provided
by perl-base. The name of this virtual package will change when the
interface between the Perl interpreter and the modules changes.
If we consider @INC part of that interface, we can use the existing
mechanism also for the few nonbinary modules using $Config{vendorarch}.
This is a new requirement that currently affects six packages in
the archive.
</sect1>
<sect1 id="binary_modules">
</sect1>
<sect1 id="binary_modules">
- <heading>Binary Modules</heading>
+ <heading>Binary and Other Architecture Dependent Modules</heading>
<p>
Binary modules must specify a dependency on either
<package>perl</package> or <package>perl-base</package> with
a minimum version of the <package>perl</package> package
<p>
Binary modules must specify a dependency on either
<package>perl</package> or <package>perl-base</package> with
a minimum version of the <package>perl</package> package
- used to build the module, and must additionally depend on
- the expansion of
- <package>perlapi-$Config{debian_abi}</package> using
+ used to build the module. Additionally, all binary modules
+ (regardless of their installation directory) and any other modules
+ installed into <tt>$Config{vendorarch}</tt> must depend on the
+ expansion of <package>perlapi-$Config{debian_abi}</package> using
the <tt>Config</tt> module. If <tt>$Config{debian_abi}</tt>
is empty or not set, <tt>$Config{version}</tt> must be used.
</p>
the <tt>Config</tt> module. If <tt>$Config{debian_abi}</tt>
is empty or not set, <tt>$Config{version}</tt> must be used.
</p>