Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Mon, May 02, 2011 at 06:09:17PM +0200, Goswin von Brederlow wrote:
> > 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.
You have made this assertion repeatedly; I have repeatedly rejected this
assertion. As long as multiarch remains a one-way transition, with biarch
or cross-compiler packages being replaced by multiarch packages (never the
other way around) and multiarch library paths always included first in the
search order, this is a non-issue and your proposed Conflicts are needless
complexity.
> 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.
No, libc6-msp430-dev would use /usr/<triplet>/include as it does today.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: