Re: [9fans] backwards-incompatible changes

[Dan Cross <cross@math.psu.edu>]

> > Ick.  Why not include a /lib/namespace.local, which can do things as it
> > sees fit?  The rationale here is that one can keep /lib/namespace the
> > same as on sources (reducing the maintenance burden), but provide much
> > the same functionality (/lib/namespace.local can include
> > /lib/addns.$sysname or something similar).
> 
> Because including /lib/namespace.$sysname is a sensible default.

Which already has another well-defined meaning and is commonly.

> Perhaps /lib/namespace.local should also be included, in the
> spirit of /rc/bin/termrc.local and /lib/ndb/local, but that's separate.

I think that'd be a good idea.

> If we did it your way, everyone who wanted to use a
> /lib/namespace.$sysname would have to create /lib/namespace.local
> and maintain that themselves.  I don't see a good reason for it.
> You should be able to customize, not be forced to.

But we're already being forced to customize /lib/namespace.$sysname,
something that is already established and in common use.  How's that
different from maintaining /lib/namespace.local?  How is having
/lib/namespace.local `forcing' you to customize?

> Put another way, we use /lib/namespace.$sysname.  Therefore, 
> the include of that should go in /lib/namespace (which we can 
> tweak) rather than /lib/namespace.local (which is left for you to
> tweak).

I'm not opposed to the idea of including /lib/something.$sysname in
/lib/namespace, but I think the naming convention is a little weird.
Why not call it /lib/addns.$sysname or something like that?  Why
overload the meaning of /lib/namespace.$sysname?

	- Dan C.