I really don't want to even look at NetBSD systems other people have
installed if they don't have some basic tools available _by_default_ in
static-linked form.  I can coerce my systems to make them look and work
the way I want them to, but it would be really bad for other people, in
general, (of course not just because I would be reluctant to support
them as-is :-) if there isn't a default way to boot to single user mode
regardless of what fat-fingered damage has been done to ld.so or the
shared libraries needed by programs which now work just fine on their own.

[ On Friday, August 30, 2002 at 18:56:26 (+0200), Julio Merino wrote: ]
> Subject: Re: keep init static? (was: Re: RFC: migration to a fully dynamically linked system)
>
> What I think is that having /sbin dynamic EXCEPT /sbin/init will cause
> confusion. If we go dynamic, everything should be dynamic. IMHO.

Personally I think that's a silly excuse.  "confusion"?  I don't think
so.  People will either be totally confused regardless of what's where,
or they'll be able figure it out with no problem.  This change to a
fully dynamically linked system alone will cause far more "confusion".

I still think it's by far best to push the special versions of binaries
compiled to support dynamic loading of add-on features into special
directories where only those users who need such features will use them
and leave everything else the way it is for now.

I.e. specifically for supporting the currently available implementation
of enhanced locale support just put dynamic-linked versions of the /bin
and /sbin programs over in /usr/i18n/*bin and be done with it.  Building
those programs is an absolute no-brainer and would require maintaining
only one more tiny Makefile to dynamically create a sym-linked tree of
"reach-over" makefiles based on the ones in src/bin/* and src/sbin/*,
and one other one-line Makefile.inc to turn off LDSTATIC for that tree.

Meanwhile the static-linked /bin and /sbin programs can either stick
with the plain (default, but compile-time optional) NLS support they
already have today.

All of Luke's ingenious but misguided work to re-create what we already
have while twisting the rest of the whole system to be fully dynamically
linked has really has been for nothing.  He created a problem by do
something we don't really need to do and which could have done with only
a tiny bit of additional build glue, and then he had to work extra hard
to provide a way to mitigate that problem.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>