Re: GLIBC 2.0.5c changes...
Nikita Schmidt <cetus@snowball.ucd.ie> writes:
> But this has nothing to do with my original point. I did not try to
> advocate symlinks. I only was a bit worried that if we used
> non-Alpha-patched headers to compile stuff on Alpha, we might
> eventually end up with wrong results. As soon as it gets fixed in
> glibc or kernel-headers, symlinks (on Alpha) will happily go away.
OK, sorry, you're right, I did ignore the actual issue in your
message---the whole kernel-headers thing is an unfortunate sore-spot,
and I'm sometimes a little knee-jerk about mistaking peripheral issues
for the issue itself.
Anyways, to address your actual question, I think the regressions I
mentioned in glibc-2.0.5c should affect all the platforms, and, based
on what David said in another message, it looks like something was
left out of the diffs. I'm sure David will put it back in if it's
necessary.
> On Friday, 14 Nov, Michael Meskes wrote:
> > kernel-headers is not obsolete at all. For instance there is no
> > modversion.h in the glibc headers.
> So, what is the story then? What goes into glibc and what goes into
> kernel-headers? Why are kernel headers distributed between two
> packages?
That's an excellent question. Perhaps David's right in that we can
now consider using the kernel-headers package instead of creating such
a large diff against glibc. I would certainly get behind that.
Of course, short term it's probably not going to happen, and I suspect
kernel-package will need some hacking to get it less intel-specific
before it can generate kernel-headers and kernel-debs for different
architectures.
Wouldn't it be cool if MILO actually supported a menu-type option like
LILO, though? No more hot-rodding your NVRAM menu to get a new kernel
version on boot-up...
Mike.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: