← Back to team overview

linaro-release team mailing list archive

[Bug 750585] [NEW] [FFe] support for making linux-libc-dev coinstallable under multiarch

 

You have been subscribed to a public bug by Steve Langasek (vorlon):

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.

** Affects: linux (Ubuntu)
     Importance: Wishlist
         Status: New

-- 
[FFe] support for making linux-libc-dev coinstallable under multiarch
https://bugs.launchpad.net/bugs/750585
You received this bug notification because you are a member of Linaro Release Team, which is a direct subscriber.