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

[Russ Allbery <rra@debian.org>]

Riku Voipio <riku.voipio@iki.fi> writes:
> On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:

>> The same principle that applies to all dpkg output to avoid ambiguity
>> would apply everywhere, whenever there's a “Multi-Arch: same” package
>> name that needs to be unambiguous, it just always gets arch-qualified.
>> The rest would stay as they are.

> That is a major waste of space of having multiple copies of identical
> files with different arch-qualified names. Is that really better
> architecture to have multiple copies of identical files on user systems?

Is it really, though?  The files we're talking about are not generally
large.  I have a hard time seeing a case where the files would be large
enough to cause any noticable issue and you wouldn't want to move them
into a separate -common or -doc package anyway.

> Another major frustration your no-shared-files proposal adds, is the
> need to split the M-A: same libfoo-dev packages to libfoo-dev-common in
> order to avoid overwriting /usr/include contents and /usr/bin/foo-config
> binaries.

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.
   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,
   assuming that you do want to keep it, you could still move the header
   files to /usr/include/<triplet> instead, which is relatively painless.

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?
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.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>