libtool: please mark libtool multi-arch: allowed
The correct solution is for libtool package to be marked as
"multi-arch: allowed" without splitting this tiny package into two
even smaller packages.
Here is the reasoning:
libtool binary package can be used in both native and cross
compilation cases, when used correctly. That is in cross-case at the
moment one typically uses libtoolize portions of the package. If one
needs something for the DEB_BUILD architecture, one can also use
/usr/bin/libtool binary. The same way /usr/bin/cc, is a DEB_BUILD
architecture specific binary.
Multi-arch annotations are not indication if a package, libraries or
tools within are meant for build/host/target architectures.
Annotating something with multi-arch headers, should be considered for
correct dependency resolution and to either relax co-installability
for multiple architectures (common case for shared libraries) or to
relax arch qualification (e.g. declare and require that one
architecture satisfies any dependency types (foreign), or that at
times it can be treated as such (allowed)).
Precisely because libtool package has dual-nature/purpose, it should
be allowed to, at times, satisfy a cross-architecture dependency. This
is the most common-case, which we should optimise for.
If one requires a host architecture /usr/bin/libtool, one would then
explicitly state libtool:native build-dependcy, which I believe is a
distinct minor corner case which warrants manual changes as part of
cross-build enablement.
multi-arch:allowed will not impact satisfying native dependencies in
the most common case (e.g. when only a single arch is enabled in the
host/chroot/builldd)
Please mark libtool as Multi-arch: Allowed.
Please do not split libtool into two tiny packages.
--
Regards,
Dimitri.
Reply to: