Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Goswin von Brederlow <goswin-v-b@web.de>]

Steve Langasek <vorlon@debian.org> writes:

> On Sun, Apr 24, 2011 at 10:46:40PM +0100, Wookey wrote:
>> I expect the multiarch paths to replace the 'traditional
>> cross-compiling' paths in due course for all target architectures,
>> including ones that aren't Debian-suported (i.e currently
>> mingw-whatever-you-call-it, avr32, msp430), for both native use and
>> cross-compiling. Steve will have to explain to me why we might want to
>> use different paths for non-self-hosting arches. It seems to me that
>> having one canonical place to look for arch-dependent files is good
>> whether you want them for running or for (cross-)building.
>
> It's not that non-self-hosting archs should be treated differently from
> self-hosted archs, but that they should be treated the *same* including the
> requirement that multiarch directories be reserved for packages of the
> corresponding architecture... even if there is no support for such a
> corresponding architecture in dpkg or in the archive.  This future-proofs
> the packages for the time being so that if at a later date we *do* add these
> architectures to the archive as architectures, we don't end up with the
> maintainers of all the base libraries having to add lots of "Conflicts:
> libc6-msp430 [msp430]" style conflicts to ensure a smooth upgrade.

I think you are wrong there. True, the package would later have file
overwrite error and would need a Replaces or Conflicts for that (which
are quite trivial to set and cheap).

One the other hand the package should have a Conflicts or Breaks on the
same package anyway, at least as soon as there is a shlibs/symbols/abi
change. Lets assume libc6-msp430 uses the cross compiler dirs. Having
both libc6-msp430:all and libc6:msp430 would mean you have 2 versions of
a single library installed in 2 different directories. That means either
packages depending on libc6-msp430:all or packages depending on
libc6:msp430 will get the wrong library. That is best avoided on
principal even if there is no shlibs/symbols/abi difference (yet).

Also the libc6-msp430-dev:all and libc6-dev:msp430 packages will both be
using /usr/inlcude/<msp430 triplet>/ and already trigger the problem you
fear.

So using multiarch dirs or cross-compile dirs a Conflicts should be
there either way. Add that the cross-compile dirs aren't allways unique
enough to work and using the multiarch dirs becomes the only sensible
option.

MfG
        Goswin