In considering this, I realized htat we have a potentially serious problem
- if you install a new libc on an older-kernel system, it may well blow up
in a way that cannot easily be recovered. So I've written a mini-policy
this is pretty much correct. in netbsd we basically say
Kernels must always have a Provides entry for the specific image that they
contain, of the form:
netbsd-kernel-image-version (i.e., kernel-image-1.6.1)
maybe 1.6 will suffice, I guess the kernel interfaces are guaranteed to
not change in one stable version. The only exception I know
it is a bug if a new kernel with (all) COMPAT options is not able to
run old software. perhaps the only exception to this is ld.elf_so,
but in general that also applies (there *are* exceptions though.)
I don't understand this - does this mean that all dynamically linked
On Fri, May 23, 2003 at 12:10:53PM +0200, Pavel Cahyna wrote:
Kernels must always have a Provides entry for the specific image that they
contain, of the form:
netbsd-kernel-image-version (i.e., kernel-image-1.6.1)
maybe 1.6 will suffice, I guess the kernel interfaces are
On Fri, May 23, 2003 at 07:06:02PM +1000, matthew green wrote:
In considering this, I realized htat we have a potentially serious problem
- if you install a new libc on an older-kernel system, it may well blow up
in a way that cannot easily be recovered. So I've written a
it is a bug if a new kernel with (all) COMPAT options is not able to
run old software. perhaps the only exception to this is ld.elf_so,
but in general that also applies (there *are* exceptions though.)
I don't understand this - does this mean that all
So, the good news is that I resolved the libc NEEDED section thing. All is
working now. As part of the stuff I've been putting off, I'm packging up
the 1.6.1 tools (netbsd-make, netbsd-libc, etc), and will probably look at
building some sort of netbsd-kernutils (things like ps, kill, etc, which
7 matches
Mail list logo