re: Proposed mini-policy for NetBSD kernel packages

[matthew green <mrg@eterna.com.au>]

   >    
   >    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.)
   
   I don't understand this - does this mean that all dynamically linked
   programs (i.e. almost all programs) will fail?

do you mean the exceptions part?  it won't be an issue for debian/netbsd
until the next one occurs :)  usually it has been alpha or mips changes
to make netbsd properly obey they ELF spec, or some such.  it means that
new with an old ld.elf_so can fail.
   
   >    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.
   
   I remember our discussion about this some time ago. KVM-reading programs
   can fail, while sysctl-reading should not, is this right? What programs

yup.

   do depend on KVM? I guess among those are netstat and fstat. What about
   ps? Its man page mentions only using /dev/kmem , not sysctl.

ps(1) was changed to use sysctl interfaces a Long Time Ago.  i've
personally verified that it works, even when running a 32 bit ps(1)
on a 64 bit sparc64 machine....