On Sat, Jun 07, 2008 at 09:50:38PM +0200, Bastian Blank wrote: > On Sat, Jun 07, 2008 at 12:06:07PM -0700, Steve Langasek wrote: > > On Fri, May 09, 2008 at 05:51:26PM +0200, Bastian Blank wrote: > > > /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.
> Yes and it was scheduled for removal since some time. Most architectures > in the glibc already stopped using them. I am not arguing that software expecting asm/page.h should not be fixed. I am asserting that such changes should not be made to linux-libc-dev during a freeze. > > 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. > Incorrect. There is another "problem" in linux/capability.h which I > consider problematic. It affects some packages and is fixed in 2.6.26. No, not incorrect. I have seen claims - not by you, but by maks - that the linux-libc-dev headers are correct *because* they're what upstream ships. > > 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. > gcc 4.3 also removed (long deprecated) support for some things. There is a very significant difference between gcc dropping support, and linux-libc-dev dropping support. Long before gcc was switched, it was discussed with the release team, and full-archive rebuild testing was done to identify the regressions that the change would introduce, and these were systematically fixed, and *then* gcc 4.3 was accepted as the default compiler for lenny. linux-libc-dev just one day dropped a header that libc6.1-dev was looking for, and then the kernel and glibc maintainers played bug ping-pong about it. That's why I'm concerned about possible freeze impacts. > > 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 > You are member of the kernel team. Feel free. I'm happy to assume responsibility for this within the kernel team, *IFF* I'm not going to have to contend with fellow team members assigning API compatibility bugs away from the kernel package. Do I have any assurance of that? -- 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]
