re: NetBSD: 1.6.1 or -current? Major discussion request.
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
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 :-)