[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposed mini-policy for NetBSD kernel packages

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
are bound to the kernel interfaces). As part of this, I'd like to try to do
some basic 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
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.

The proposed policy is attached, and I'd *really* like feedback on this,
especially from folks who are more intimately familiar with NetBSD's kernel
Joel Baker <fenton@debian.org>
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).

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:


Binaries or libraries that depend on or interact with kernel functionality
should have a suitable Depends (or Pre-Depends or Build-Depends, as
suitable) entry of the form:


This will ensure that they are only installed on systems with a kernel
image that can support them. (It does not make it impossible to do
something quite braindead, such as booting an older kernel with a newer
libc, but it should in theory protect one from ending up in a state where a
simple reboot to the appropriate kernel isn't possible).

Attachment: pgpWWQ5Fj7KPH.pgp
Description: PGP signature

Reply to: