Hi Jamie, On Fri, Apr 08, 2011 at 10:14:54PM -0000, Jamie Strandboge wrote: > To me, this is a pretty big change less than three weeks to release. I > appreciate the hard work that went into examining potential breakage and > on the surface things seem generally ok and workable, but considering > how part 1 of the mutliarch changes went, I have some concerns (not > being critical here, just that these are rather fundamental changes we > are discussing and I think that is worth some pause).
Yes, I recognize the cause for your concern and understand completely where you're coming from. If this is considered too high-risk, it's not the end of the world if we don't include this change - it would make it easier for progress to be made on multiarch between now an oneiric opening, but it's not critical. I think if anything else did turn up that broke because of this change, it would be less effort to fix that than it would to maintain an out-of-archive linux package. And there's definitely much less risk here than with the earlier change, because software has much less reason to probe paths to asm/*.h than to probe paths for libraries. > Could something not be coordinated with Lucas? I thought archive rebuilds > for him were in the neighborhood of 8 hours (that is total hearsay-- I > don't actually know). That's a good idea; I've pinged him on IRC, hopefully he'll get back to me soon. If we can get a rebuild scheduled and I can commit to addressing any new build failures that turn up as a result, are you happy for this change to go forward in the meantime? If not, I think we should forgo this entirely for natty due to the timing. > @Steve, In all honesty, I have a hard time imagining you letting this > change through if you were release manager. :P I would be asking all the same questions if the tables were turned, but the thing about being the developer proposing a change is that it changes your perspective in ways that are difficult to filter out, which is why members of the release team also use the FFe process. :) -- 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/ [email protected] [email protected] -- 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: Fix Committed Status in “linux” source package in Natty: Fix Committed Status in “linux” source package in Oneiric: Fix Committed 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. _______________________________________________ Mailing list: https://launchpad.net/~linaro-release Post to : [email protected] Unsubscribe : https://launchpad.net/~linaro-release More help : https://help.launchpad.net/ListHelp
