Re: Update Debian policy for Multi-Arch
On 03.05.2016 13:25, Simon McVittie wrote:
On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
A large number of packages, particularly development packages, are not
multi-arch aware.
...
3.10 Multi-arch support
Packages must be multi-arch aware and architecture-specific
development packages must be tagged as Multi-Arch: same.
See <https://wiki.debian.org/PolicyChangesProcess> if you want to push
this forward.
However, I suspect the Policy editors will object that Policy normally
documents what is already broadly true, not what someone wants to be true
(even if the desired state is widely agreed to be what the project wants).
What is "broadly true"? If you look at the whole archive, multiarch certainly
doesn't apply to the term "broadly". If you look at a subset, like packages
involved in bootstrapping a essential or build-essential environment, or looking
at a desktop image, then the term "broadly" applies more.
A mass-bug-filing or mass-patch-attaching to make libraries and development
packages Multi-arch: same would be more in line with how things like this
usually go.
Sure, but even if you provide patches in these bug reports, some package
maintainers ignore these patches or even refuse to apply those because *they*
don't like multiarch, blocking goals like cross-buildability.
So what would make more sense would be to first establish best practices to make
packages multiarch aware, and then file bug reports pointing to such best
practices. Config scripts is one example, another is one packages bundling
shared libraries and plugins in the same binary package.
Note that for the subset of development packages that contain
architecture-specific binaries in $PATH (most commonly "foo-config"), it is
not trivial to switch to Multi-arch: same without breaking existing
reverse-dependencies.
That doesn't have to be true. For this particular example, you could:
- split out the binary into a new package (e.g. splitting out the
seldom used libtool binary into libtool-bin) and then fix things.
- modifying the script to remove multiarch bits like removing paths
inc --cflags or --ldflags/--libs options, because these libs are
on the standard path anyway.
- removing options like --includedir/--libdir and returning an
error when this option is used. Most of these scripts are
historical, and ship a pkg-config file as well. Of course things
can break, but not silently.
Unbundling plugins and shared libs is probably more problematic, assuming you'll
keep the name for the shared library package, and introducing a new binary for
the plugins. You'll now have to find out for each reverse dependency of the
original library package, if plugins are required or not.
Matthias
Reply to: