Re: 4.0 chroots, threading, and builds

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 29 Sep 2008 09:35:36 +0000
    From:        Andrew Doran <ad%NetBSD.org@localhost>
    Message-ID:  <20080929093536.GE29458%hairylemon.org@localhost>

  | If a one line addition to /etc/ld.so.conf is acceptable for you, then it
  | fits your use case nicely (regularly swapping back and forth between 4.0 and
  | 5.0 kernels).

The way I upgrade is by (compiling and) booting the new kernel.
Absolutely nothing else changes.   If everything works, then the new
userland can be tested in a chroot to make sure it works, and if all is
OK, it might eventually get installed.

While that's happening, absolutely nothing changes in the base system
userland (nothing new installed, no bugs fixed, nothing.)  For all
practical purposes you can imagine that everything is on physically read
only media.

If anything from the old system breaks, then the kernel goes back to the
old one, and I wait until the kernel bug that caused the failure gets
fixed, then I get to try all this again.   Occasionally I might get
convinced that a program bug has been revealed by the new kernel, in that
case I fix the bug on the old system, make sure it gets tested and
everything is OK, and then go through the testing procedure all over
again.

To make this work, there cannot be "you need this extra library installed"
or "this changed library installed" or "this extra line in ld.so.conf"
or anything else like that.

Binary syscall compatibility is crucial, as it is the one thing I know
that old applications can rely upon.   Linking against an updated library
is nice, but if I don't control the source, I have no idea how much
of the original library is really used by linking, and how much of it
(perhaps altered slightly) the application designed just happened to
incorporate into his code (unclean stuff for sure, but people do all
kinds of things to make their products work).   I know they can't have
altered the kernel, so I know that as long as the kernel will keep running
old binaries, with an identical interface, then all those old programs
will keep on working, no matter how bizarre they are (and I never need to
know just how ugly it all is.)

I also do building in chroot environments, where the (automated)
procedure is to unpack the X.0 release sets (always .0 so the end product
will work on all X.n and (X+y).* systems), build and run programs, and
package the results.

No room there for fiddling the X.0 environment - any changes to it and
first I never really know whether or not the fiddle is going to alter
things in unsafe ways or not, and second, because if I need to do that,
and then later someone really running an X.0 system reports a problem,
I have no way to exactly duplicate their environment to track down
what is going wrong - just a trivial thing like a few extra bytes
allocated in a loaded library can change the memory map around enough
that bugs remain hidden (because they happen not to touch anything critical)
or manifest in wildly different ways.

I'd like to thank Bill for all the work he's doing on revivesa - to me
that's crucial for keeping any future for NetBSD, and perhaps more importantly
to NetBSD than whether or not I was to keep using the system, to its
reputation for keeping compatibility - truly one of the hardest things to
manage, but also one of the most necessary.  If that is lost, then the
next thing that someone will decide to break, citing this precedent, might
just be the thing that you most depend upon.

kre