Re: backwards compatibility was Re: Uploaded kernel-package 3.61
On 19 Feb 1998, Manoj Srivastava wrote:
> Hi,
> >>"Juan" == Juan Cespedes <cespedes@debian.org> writes:
>
> Juan> On Thu, Feb 19, 1998 at 12:15:01PM +0100, Christian Leutloff
> Juan> wrote:
> >> srivasta@debian.org writes:
> >>
> >> > Hence, now kernel-source-* packages compiled with this
> >> kernel-package shall not provide any sort of kernel-headers. For
> >> the sake of backwards compatibility, /usr/src/linux-$version
> >> symlinks are still being provided (as people may upload newer
> >> kernels while keeping an older libc6-dev around, which depends on
> >> /usr/src/linux-2.0.32.
> >>
> >> The symlinks should go *now*
>
> Juan> Agreed. Manoj, we will break many people's setup if we change
> Juan> /usr/src/linux*. It's against policy to use them locally, but
> Juan> many people don't know it and they will complain.
>
> Juan> We won't need them at all if Dwarf releases the new libc6.
>
> Will people share the flack with me when people upgrade
> kernels without first upgrading libc6-dev, and having compilation
> break for them? Also, having trouble when they try to remove old
> kernels? Cause if you remove the symlinks now, old kernel image
> postrm shall bomb out.
It shouldn't bomb out, of course. If somebody has a directory (not a
symlink) /usr/src/linux and it contains a kernel tree, what happens when
the postrm is run?
> If indeed it is the consensus to dictate such (IMHO
> unnecessary) breakage, far be it for me to stand in the way.
I think if the "Good Thing To Do" has the consequence that we break the
system for people who follow hamm, it should be done. They are supposed to
expect that once in a while, that's why it's called unstable. A system
that is upgraded from one stable release to another shouldn't break, of
course.
> However, I feel this is a quality of implementation issue. I
> think the links should be phased out.
Yes, the links are quite dangerous. I think it is consensus that they
shouldn't exist in a stable Debian 2.0, but I can also imagine that trying
to remove them may break a lot.
> Opinions, people?
Yes, I think I have one. But first, let me summarize the problem to make
clear what we're talking about.
libc6-dev now depends on kernel-headers-2.0.32. The latter puts the
headers in /usr/src/kernel-headers-2.0.32 and puts symlinks to them in
/usr/src. The libc6-dev package also contains symlinks to this directory.
The kernel-headers-2.0.32 package contains:
drwxr-xr-x 3 root root 1024 Jan 9 14:59 /usr/src/kernel-headers-2.0.32/
lrwxrwxrwx 1 root src 21 Jan 9 15:04 /usr/src/linux -> kernel-headers-2.0.32/
lrwxrwxrwx 1 root src 21 Jan 9 15:04 /usr/src/linux-2.0.32 -> kernel-headers-2.0.32/
The libc6-dev package contains:
lrwxrwxrwx 1 root root 33 Feb 11 14:30 /usr/include/asm -> /usr/src/linux-2.0.32/include/asm/
lrwxrwxrwx 1 root root 35 Feb 11 14:30 /usr/include/linux -> /usr/src/linux-2.0.32/include/linux/
Now, is there another reason for the existance of the
kernel-headers-2.0.32 package, other than that libc6-dev needs it? If
there isn't, I suggest a package that contains only the headers that are
needed by libc6-dev and that they are placed directly under /usr/include/.
Headers for all architectures could be included, but I don't think they
are necessary.
So, you could get:
libc6-dev:
Depends: kernel-headers-for-libc-2.0.32 (or whatever it's called)
Contains:
/usr/include/asm -> /usr/include/asm-<arch>/
kernel-headers-for-libc-2.0.32:
Contains:
/usr/include/asm-<arch>/
/usr/include/linux/
Only really big problem would be the removal of old symlinks in /usr/src,
I think.
Remco
--
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: