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

Re: Proposed mini-policy for NetBSD kernel packages

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 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.

Yup. This is what I was working with.

>    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.)

Ah. Good to know, definitely. I doubt anyone will much care about the
ld.elf_so transition on any of the current platforms (if we get one that
hasn't transitioned yet, well... we'll worry baout it then, IMO).

>    [ .. ]
>    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.

This was actually meant (and perhaps should be rewritten) to mean that the
Provides should reflect the compat options the kernel was built with.

Also, I'm considering whether we should list -1.6 as a minimum version
known to work or be supported by Debian in any direct fashion. (Still
having the -compat entries for older stuff would perhaps be useful for 3rd
party software...)

>    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.

The system is certainly extendable in a coherent manner, or at least
that's my goal. :)
Joel Baker <fenton@debian.org>

Attachment: pgpDGc6faNziR.pgp
Description: PGP signature

Reply to: