Re: Bug#480295: [alpha] missing asm/page.h
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: