On Sat, Jun 07, 2003 at 01:45:40PM +1000, matthew green wrote: > > 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.
It probably isn't. There *might* be some care needed to avoid pulling in pthread-related stuff, but overally, I think it would be doable. > 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. The only reason it isn't there yet is because I haven't gotton the final form that's going into -current. :) > 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. Well, okay. The *major* ones happened post-1.6, but it's a long and ongoing saga. :) > 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. Didn't know that, but one more reason :) > 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 don't generally have issues with -current, though I don't think I'd want to claim we should release with that as the core. Mostly, the question was "should I schedule a Flag Day and wipe out the current NetBSD archive" (well, okay, probably 'move it aside' for now), and do a set of builds based on -current. So far, the concensus on IRC and here seems to be 'yes'. -- Joel Baker <[EMAIL PROTECTED]>
pgpTnKFkpOcRd.pgp
Description: PGP signature
