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