On Wed, Jan 10, 2007 at 01:16:40AM -0800, Stephen Hahn wrote: > * Mike Kupfer <mike.kupfer at sun.com> [2006-12-15 10:34]: > > > There's a discrepancy in the CLI stability between the /usr/bin items > > (Volatile) and the /usr/gnu/bin items (Uncommitted). Why is that? I'd > > expect them to be the same. > > This came up earlier (and Danek raised it as well)--it allows a > project team to consider replacing the default environment's variant.
Hunh. So what you're saying is that you're not quite committed, but a bit more than haphazard about keeping /usr/gnu/bin/foo the GNU version of foo, but /usr/bin/foo may be the same as the GNU version or it may be the BSD version, or it may be some LGM version, at your whim, to be changed at any point? That's interesting, and probably valid, but I don't think that's the way most people read the interface tables. What they're going to see (I think; 'cause that's what I see) is that you've got one command with two locations, and that the /usr/bin version of the command is likely to change (and possibly incompatibly) in a patch release -- presumably to always match the provider's latest version, be that GNU or whoever -- and the /usr/gnu/bin version of the command will change only compatibly in a patch release. That suggests divergence between the two -- you're stuck with only compatible change to the /usr/gnu/bin version across a set of updates, while you can change the /usr/bin version arbitrarily in the same releases. So they start off the same, but don't evolve together. Which is very odd. Danek
