re: NetBSD: 1.6.1 or -current? Major discussion request.

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

   1) __cxa_atexit - This can be worked around (GCC is patched to avoid
   using it), but it's fugly and really should be fixed. Conveniently, in
   -current, it is (after a PR requesting it). Can be backported, though I'm
   not entirely sure I'm comfortable with that, given how it affects every
   single C++ program ever compiled.

i don't see why it would really be such a problem to backport this.
   
   2) ftw()/nftw() - This will be going into -current in a few days (and
   replace the workaround jftw package). It really belongs in libc, not in a
   separate library, and it will be there. Backporting this should be fairly
   trivial, as it's completely new code that doesn't really interact iwth
   anything else except for calling the pts suite. APT absolutely must have
   this to build, however. (And it's a POSIX requirement, too.)

this should definately go into the netbsd libc.
   
   3) POSIX threads - This is a killer; tcl8.4 *must* be threaded, and is
   breaking horribly with GNU pthreads (both 1.x and 2.x). Python depends on
   TCL; a whole *lot* of things depend on python (or TCL), or on something
   that does. The threading changes are so extensive that it's probably more
   or less implausible to backport them to a 1.6 tree, since they were
   started on post-1.6-release code.

actually the threading changes were started a couple of years ago :)
you are 100% correct that attempting to backport would be a complete
waste of time, however.

   4) Not-really-an-issue - i386 SMP. There is a working release of the
   i386/SMP branch against 1.6(.1), so it's by no means crucial, but -current
   supports this in the core code, and it would be nice to support it where we
   can (but an SMP patch is probably sufficient, if staying on 1.6.1).

also - sparc SMP only exists in -current.
   
   So the question is - should I/we bail on trying to build a release on
   1.6.x, and do one from -current instead? If it weren't for the POSIX
   threads problem, I'd consider it, but that change is so invasive *and*
   pervasive that it affects basically every application on the system in one
   way or another, and it is COMPLETELY incompatible with anything compiled
   against GNU pth pthreads - so the transition to 1.7 would be an utter
   and royal pain in the arse to manage, and/or require a flag day (remove
   evreything in the archive, upload new stuff). I can do flag days on my
   archive easily enough (and have been considering it, since the build
   environment is currently far cleaner than it used to be), but it will be a
   very bad sign to the ftpmasters if we have to do it once we're in the main
   archive.
   
   Personally, I vote for rebuilding based on -current; however, since I'm far
   from the only person doing this, and I'd like to have some chance of not
   crossing over each other's work, I'd like to hear other opinions.


the alternative is to get a modern kernel & libpthread (& libc?
i'm not sure) but to leave the rest of userland alone.  then again
i've been running netbsd-current systems almost exclusively for
nearly 10 years (i have run some work/customer machines with
releases... but never my own.)  -current works well nearly all
of the time.  if you pick a snapshot, try it out for a while and
if it is good, use it.


i could expand more if you want :-)



.mrg.