** Description changed: - 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. + 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/750585 Title: [FFe] support for making linux-libc-dev coinstallable under multiarch -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
