Re: [9fans] backwards-incompatible changes

["Russ Cox" <rsc@plan9.bell-labs.com>]

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

We have about 20 namespace.$sysname files here, and every
one of them was only appending to the standard name space
rather than replacing it.  And they weren't doing a good job either --
many of them had diverged from namespace since being created.
The common case thus appears to be append rather than replace.
Further, we couldn't see any reason you'd really want to replace.
Hence we changed the default interpretation.   The only reason we
added the ``clear'' verb was to make a smooth transition possible.

I think the only reason namespace.$sysname sounds weird to you
for ``things to run after running namespace'' is that you've already
got it stuck to ``things to run instead of running namespace.''  
I don't think there's anything inherently strange about the new
convention.

> Why overload the meaning of /lib/namespace.$sysname?

We didn't overload it.  We replaced it.  /lib/addns.$sysname
sounded clunky, and we didn't have any better ideas.
Think of it as fixing a bug in the way namespace.$sysname
works. 

> 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?

The fact that newns consults /lib/namespace.$sysname is useful.
Unless I misunderstand you, you are proposing that /lib/namespace
should include /lib/namespace.local, which should, if the user feels
like it, include /lib/namespace.$sysname.  So you're forced to create
/lib/namespace.local in order to get this useful commonly-used 
not-really-local feature of including namespace.$sysname.
That feels like a mistake.

Russ