On Wed, Dec 03, 2003 at 04:48:34PM +1100, matthew green wrote:
>
> This may be possible under NetBSD as well (especially with a generous
> helping of COMPAT option enabling), but given the number of dire warnings
> the manuals all bear about building things in the correct order, I'm not
> willing to trust that it's flexible enough to start doing interesting
> things with.
>
>
> FWIW, generally it's considered a major bug if a new netbsd kernel[*]
> fails with an old userland. (_maybe_ ld.elf_so needs to be updated
> in some rare cases that only apply to some platforms once.)
For those situations, we can express (reasonably simply) a "requires
libc >= <version>", rather than a strict versioning lockstep; not at all
unreasonable. And, IIRC, fairly rare on the more popular platforms, these
days, and likely to appear only over major release points (1.5 -> 1.6, 1.6
-> 2.0, not 1.6 -> 1.6.1).
> most of the warnings are (somewhat) dated with the new ./build.sh
> method of building netbsd. in general the only rule one has to adhere
> to is "userland age =< kernel age". and don't "build to DESTDIR=/" :-)
The only quirk, then, is that we'll have issues with doing full system
upgrades - you won't be able to do the equivalent of "run woody libc with
potato kernel".
> but even that's not always the case - a 1.5 kernel can run nearly all
> of the 1.6 userland (this isn't going to be true of 1.6 and 2.0, nor
> is it true in most other major releases.)
Noted; unfortunate, but noted. It's actually this that I wish wasn't so
true (except maybe over major-number releases; converting from Linux 1.x to
2.x does have similar quirks). I vaguely wish the userland (or at least the
core libraries and utilities) could detect *older* kernels, and fall back
to legacy support mode (possibly with a deprecation warning that could be
turned on via environment variable, or such).
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpC05P7HmK6J.pgp
Description: PGP signature