re: Proposed mini-policy for NetBSD kernel packages
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 that if you
have a new kernel (with old "options" enabled) an old userland should
work fine, but new userland with old kernel is completely unsupported.
covering a way to prevent this (in the absence of versioned Provides; we
can't just Provide: netbsd-kernel (1.6.1) in any form). One thing to be
careful of, and I'd like some refresher on this point, is whether the
COMPAT stuff in the kernel can provide old interfaces sufficiently well
that having, say, a -current kernel with COMPAT for 1.6.1 means you can
sanely use 1.6.1 libc or kernel-reading tools.
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.)
[ .. ]
NetBSD requires that the kernel and core libraries stay in fairly tight
sync; to this end, a special set of meta-packages are used for Provides (to
work around the fact that Provides can't be versioned, and the fact that a
given kernel can support older releases, but does not always do so).
as i said above, it's a bug if a new kernel fails to run old userland.
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)
Additionally, kernels must have a Provides entry for *each* of the
compatibility levels they are compiled to support. FIXME: document how to
check this. These Provides entries are in the form:
netbsd-kernel-image-compat-<version>
this is a great idea. i think perhaps even more provides might be
useful for other kernel options... but you can figure that out later
i'm sure.
.mrg.
Reply to: