2.0.33 headers break progs in 2.0.34 kernels

[Dale Scheetz <dwarf@polaris.net>]

I'm in a dilema of sorts for several reasons. Debian is due to release in
about a week, and kernel headers have broken some things.

Here is the report:

> The hd_driveid struct in linux/include/linux/hdreg.h got bigger.
> Calling the HDIO_GET_IDENTITY ioctl() (a published interface to the
> ide subsystem) will cause a 2.0.33 or before application to trash its
> data segment/stack under 2.0.34.  If the application is built against
> 2.0.34 (and more importantly the 2.0.34 headers), the ioctl is safe
> under 2.0.33.

The size of a data structure seems to have grown, resulting in a program
compiled with 2.0.33 headers to crash when run on a 2.0.34 kernel, if it
uses this ioctl call.

Since the program compiled against a 2.0.34 kernel header will work on a
2.0.33 kernel, compiling those packages against that header fixes the
problem.

The question for me is, how likely are other things going to break if I
move the glibc package up to the 2.0.34/35 kernel headers? This close to
the release, I am reticent to make such a "drastic" change, specially when
the known programs can be delivered properly by compiling them special.

I guess I am mostly fishing for a better approach. Anyone have a
suggestion?

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-