+++ The Wanderer [2013-05-06 09:36 -0400]: > > I don't know whether it would be practical, but one thing I would like > to see included as an explicit goal is the completion of multi-arch -dev > support.
I think it's eminently practical. > There is functionality provided by the old ia32-libs-dev package which > is not apparently possible - short of installing the necessary headers > and so forth by hand, and maybe not even then - with multi-arch library > packages, unless multi-arch -dev packages are also supported. Since they > aren't, this means the transition from ia32-libs to multiarch introduces > a regression. > > Since I use some of the functionality which appears to be lost in that > regression, I would hope for fixing that regression to be one of the > goals for the next release. > > > I understand that the necessary specification for letting this be > possible has not been completed, and that work on that is ongoing. In fact this work has been done, at least to a reasonable approximation. A large number of multiarch -dev packages have been put in Ubuntu and tested there for building and cross-building against. It didn't actually need any significant changes to the multiarch spec (just a decision to leave arch-independent headers in /usr/include and move arch-dependent headers to /usr/include/triplet). So long as the toolchain knows to look on both those paths by default nearly everything 'jsut works'. There are a few wrinkles about finding headers (python was a bit ugly IIRC), and we may find a few more but this seems to work well in practice. Updating the multiarch spec to record this info just needs doing. Telling apt to assume that arch:all Build-dep: packages are M-A:foreign also dramatically improves the effectiveness of multiarch for -dev packages (without having to wait until everything has actually been explicitly marked): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666772 Again this has worked nicely in Ubuntu and I see no reason not to do it in Debian too (although we could decide to explictly mark every package instead if we really wanted the makework). > I am > certainly not attempting to bash anyone for the regression; delaying the > release of wheezy until the work could be completed, such as would have > been necessary to avoid the regression without delaying multiarch, would > plainly not have been a reasonable option. Indeed. > That said, I'd obviously prefer this not to continue to be delayed any > longer than necessary, and including it on the list of release goals > seems like an appropriate way of raising its profile (and/or its > priority) in pursuit of that. I'm all for that. If anyone has any objections, speak up. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130507020450.gb2...@stoneboat.aleph1.co.uk
