linaro-release team mailing list archive
-
linaro-release team
-
Mailing list archive
-
Message #00124
Re: [Bug 750585] Re: [FFe] support for making linux-libc-dev coinstallable under multiarch
Thanks for the review, Martin.
On Tue, Apr 05, 2011 at 09:00:25PM -0000, Martin Pitt wrote:
> Out of interest, why is it necessary to have co-installable -dev
> packages? Is that only for convenience, to avoid having e. g. a i386
> pbuilder/build chroot on amd64? So far I thought that multiarch was
> pretty much a runtime-only thing.
In the grand scheme of things: because when cross-compiling, you may have to
build part of your package for both the host and build architectures as part
of a single package build. Various packages will build tools which they
then execute as part of the build. In some cases, this means having both
host and build versions of the build dependency installed. That's *very*
frequently the case for libc-dev.
Sorry to mislead you into thinking multiarch was runtime only. That was the
scope of <https://wiki.ubuntu.com/MultiarchSpec>, but that's only one piece
of the puzzle (the core around which everything else gets built). In the
long term, I have my sights set much higher. :)
> For limiting the breakage, would it be reasonable to ship a
> /usr/include/asm symlink which points to the "main" architecture? Or
> would that hide potential bugs too much?
Where do you point the symlink, and what package do you include it in? You
can't have each linux-libc-dev package shipping this symlink with a
different target, that breaks co-installability.
--
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@xxxxxxxxxx vorlon@xxxxxxxxxx
--
You received this bug notification because you are a member of Linaro
Release Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/750585
Title:
[FFe] support for making linux-libc-dev coinstallable under multiarch
Status in “linux” package in Ubuntu:
New
Bug description:
FFe justification: now that multiarch support for runtime libraries in
the base system is available in the archive, the next step in this
process is multiarch coinstallability of -dev packages. Although most
of the remaining work on multiarch -dev can and will take place in ppa
for natty given where we are in the release cycle, any -dev package
tree has at its root linux-libc-dev which is built from the 'linux'
source package - the package which is updated more frequently than any
other by SRU. Rather than trying to keep up with SRUs, or
artificially inflating the version of a linux-libc-dev-only package
build in ppa, it would be welcome if a multiarch-ready linux-libc-dev
could be included in the archive for natty.
Risks: anything that looks directly in /usr/include/asm for headers
will have problems with this change; anything that uses the system
include path from the compiler will not. My best efforts at examining
the archive for this issue (see below for details) have turned up only
four packages in main and universe that are affected: three C library
implementations, and bash-completion. Updating these packages in
concert is manageable (patch for eglibc is ready, patches for the
others are in preparation), but there's always some risk that the text
search on package sources has missed something, and there wouldn't be
room for another full archive rebuild before release to catch other
breakage.
Details:
In order to have coinstallable multiarch -dev packages of any sort, linux-libc-dev first needs to be coinstallable since libc-dev depends on it. This seems to be straightforward to achieve; only the asm directory needs to be moved to the multiarch directory path, all the other header files appear to be (sensibly) architecture-neutral and can be shared between architectures.
The compiler will find /usr/include/<triplet>/asm for the
corresponding architecture with no problems; I've done a number of
test builds that work just fine this way. The only trouble is with
software that walks the filesystem looking for asm/<foo>.h includes
instead of trusting the compiler to resolve them. It's unlikely that
software should need to do this since the asm headers should as a rule
not be directly included from userspace anyway, but the chances are
not zero. I didn't expect nearly as many packages to break as did by
the move to /usr/lib/<triplet>, either, so it seems my faith in the
sanity of upstream build systems is generally misplaced. And I don't
think we have time to discover any resulting issues with another
archive test rebuild and fix the resulting packages before the natty
release.
References