Re: Please test gzip -9n - related to dpkg with multiarch support
Neil Williams <email@example.com> writes:
> Russ Allbery <firstname.lastname@example.org> wrote:
>> There are two main cases for libfoo-dev that I think cover most such
>> 1. The header files are architecture-dependent (definitions of data member
>> sizes, for example), in which case they need to be arch-qualified
>> anyway if you're going to allow multiple libfoo-dev packages to be
>> installed for different architectures.
>> 2. The header files are architecture-independent, and the only
>> architecture-dependent content inside libfoo-dev is the static library.
> So the symlink would have to move to the shared library alongside the
> other symlink?
> ./usr/lib/x86_64-linux-gnu/libgpelaunch.so -> libgpelaunch.so.0.0.0
> ./usr/lib/x86_64-linux-gnu/libgpelaunch.so.0 -> libgpelaunch.so.0.0.0
Oh, good point, I'd forgotten that for multiarch the symlink is
architecture-dependent. So yes, the -dev package is inherently
We can't move the symlink to the shared library package because then the
shared library packages aren't co-installable.
> pkg-config files are also Multi-Arch sensitive:
> Those need to be in Multi-Arch paths:
Correct. Anyone converting a library to multiarch should already be
moving them, IMO. I have with all of mine.
> I would drop the .a but that doesn't mean I can make the -dev package
> Multi-Arch: foreign.
You're right. -dev packages are going to have to be multi-arch: same.
I think the hardest problem is then going to be the documentation
(including man pages) that are normally now in the -dev package, and any
-config scripts or the like. We already have multiarch path solutions for
header files and for the symlinks, although it requires duplicating the
header files for each architecture.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>