Riku Voipio <riku.voi...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haz1rtex....@windlord.stanford.edu
