On Fri, May 09, 2008 at 05:51:26PM +0200, Bastian Blank wrote: > reassign 480295 libc6.1-dev > thanks
> On Fri, May 09, 2008 at 05:33:40PM +0200, Aurelien Jarno wrote: > > Matthias Klose a écrit : > > > In file included from ../../bfd/trad-core.c:45: > > > /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or > > > directory > > > make[5]: *** [trad-core.lo] Error 1 > > /usr/include/asm is provided by linux-libc-dev, not by libc6.1-dev. > /usr/include/asm/page.h is _not_ provided by linux-libc-dev, but > exclusivly used by /usr/include/sys/user.h which is included in > libc6.1-dev. /usr/include/asm/page.h *was* provided by linux-libc-dev in 2.6.24 and earlier. Time and again I see this position taken by members of the kernel team that any changes that are made to the API of linux-libc-dev are correct, and anything that relies on the previous behavior of linux-libc-dev is buggy. While many times (such as in this case) it is technically correct that these packages are depending on features that they shouldn't, linux-libc-dev is still transitively build-essential, and this is an irresponsible way to maintain a build-essential package. We can't have assumptions about build-essential APIs holding true for three quarters of a release cycle, only to be broken right as the freeze is starting merely because the upstream kernel has made changes. This particular API change is now water under the bridge - all the packages I know of that were affected by it have been fixed to build again - but that's no guarantee that other packages won't be broken in another future kernel upload. I see only a few options here to keep kernel API changes from derailing the release process: - the kernel team should commit to maintaining the APIs of the current linux-libc-dev throughout the freeze, in spite of any upstream changes - the kernel should be frozen for lenny at this point to avoid any further changes to the set of exported kernel headers - linux-libc-dev needs to be broken back out of the kernel again and maintained separately if it can't comply with the freeze requirements when maintained in-tree. What's the best way forward here? Thanks, -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
