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

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, 08 Feb 2012 11:56:06 -0800
Russ Allbery <rra@debian.org> wrote:

> There are two main cases for libfoo-dev that I think cover most such
> packages:
> 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

That's going to need a Replaces: in the lib against the -dev.

pkg-config files are also Multi-Arch sensitive:

Those need to be in Multi-Arch paths:

>    In this case, if you want to make libfoo-dev multi-arch, I would
>    advocate seriously considering just dropping the static library and
>    making the -dev package arch: all.  I think static libraries are
>    increasingly of very questionable utility on a Linux system.  But,

I would drop the .a but that doesn't mean I can make the -dev package
Multi-Arch: foreign.

> foo-config binaries, as opposed to pkg-config files, are indeed going to
> continue to be a problem in model 2, but they're a problem anyway, no?

... yes...

> There's no guarantee that the amd64 and i386 version of a package will
> want the same flags, so we really need some way of having a
> multiarch-aware verson of the -config script.

It's not just amd64|i386, Multi-Arch - to me and probably Riku - is
about amd64|armel etc.


Neil Williams

Attachment: pgp8mJBySrNgq.pgp
Description: PGP signature

Reply to: