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.) I don't understand this - does this mean that all dynamically linked programs (i.e. almost all programs) will 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 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. Bye Pavel
Re: Proposed mini-policy for NetBSD kernel packages
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 about is ipfilter which changed between 1.6 and 1.6.1 and this could be solved by having a special Provides entry for ipfilter and making the ipfilter userland tools a separate package. Bye Pavel
Re: Proposed mini-policy for NetBSD kernel packages
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. And how are such situations handled in netbsd? Especially when aal programs are dynamically linked now? 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. I assume this means yes. 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 Could you please provide a more exhaustive list of kmem reading programs (if you know it?) Thanks Pavel
Re: Proposed mini-policy for NetBSD kernel packages
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 guaranteed to not change in one stable version. The only exception I know about is ipfilter which changed between 1.6 and 1.6.1 and this could be solved by having a special Provides entry for ipfilter and making the ipfilter userland tools a separate package. Possibly, but I'd really be more comfortable not trying to guess. For the vast majority of things, the -compat-1.6 that would presumably be turned on (or present by default, if it doesn't require a compat option) should suffice. The few things for which it wouldn't are intimately tied to the kernel, and potentially to certain kernel options being enabled. -- Joel Baker [EMAIL PROTECTED] pgpCtbLz4VzHW.pgp Description: PGP signature
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 [EMAIL PROTECTED] pgpsLKGilGd4G.pgp Description: PGP signature
re: Proposed mini-policy for NetBSD kernel packages
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. And how are such situations handled in netbsd? Especially when aal programs are dynamically linked now? it is really only a problem if someone does a partial upgrade of their system, which means they did it manually. it's obviously not really an issue for new installs and the upgrader will install a new ld.elf_so. 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. I assume this means yes. yes :-) 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 Could you please provide a more exhaustive list of kmem reading programs (if you know it?) lets see: - ipfilter (ipf, ipnat, etc.) - dmesg - tickadj(?) - top - gdb (this is a special case though - it's *supposed* to do that) - identd used to, but may not anymore... (maybe only in -current?) - rpc.rstatd(?) - ccdconfig(?) - savecore - fstat (maybe not anymore?) - ipcs(?) - netstat - nfsstat - pmap - systat - vmstat - w/uptime (maybe not?) - ifmcstat(?) - kgmon(?) - mlxctl(?) - pstat - slstats - trpt - trsp looks fairly complete if too many... .mrg.
