From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 27 Mar 2010 14:09:25 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <32d987d51003271058o5a4bd5awd2d206e39cfc8285@mail.gmail.com> References: <20100325114948.GA7249@polynum.com> <31C84C15-2EE3-46CA-BE9F-48F20886ADF7@fastmail.fm> <202b36ec0f14adf4b09e53052147ccc8@brasstown.quanstro.net> <32d987d51003271058o5a4bd5awd2d206e39cfc8285@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] Man pages for add-ons Topicbox-Message-UUID: f5d309fe-ead5-11e9-9d60-3106f5b1d025 > > how does history(1) work in the face of a complicated namespace? > > we get buy now because the rules are pretty simple.  if you want to > > find how the modifications to /386/lib/libc.a, you know where that > > is.  if you bind 100 packages on top of /386/lib, it becomes necessary > > to deconstruct namespaces continually.  the abstraction of namespace > > starts to break down. > > > > this also breaks plumbing while debugging with acid unless quirky > namespace is global, but then if it's global why do you need the binds! in order for a namespace to be non-empty, it will need binds or mounts somewhere. even a "global" (i'm assuming by global you mean in /lib/namespace) bind will not work well with history. since the namespace isn't fancy enough to do rewriting based on pattern matching. (thank god!). i suppose you could write a script, but such a script would need to generate a set of binds for each day of the dump. are you ready for a 350*(1 + 2136) line namespace? - erik