From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200303260209.h2Q29Qt20533@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] backwards-incompatible changes In-Reply-To: Your message of "Tue, 25 Mar 2003 20:53:04 EST." <86e7f579a8ed2eb7e874334249dc5b77@plan9.bell-labs.com> From: Dan Cross Date: Tue, 25 Mar 2003 21:09:26 -0500 Topicbox-Message-UUID: 84489218-eacb-11e9-9e20-41e7f4b1d025 > > 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.