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.
> 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.
> 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.
> 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.
Bastian
--
Too much of anything, even love, isn't necessarily a good thing.
-- Kirk, "The Trouble with Tribbles", stardate 4525.6
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
