* James Carlson <james.d.carlson at Sun.COM> [2007-01-30 13:55]: > Stephen Hahn writes: > > * James Carlson <james.d.carlson at Sun.COM> [2007-01-30 12:03]: > > > Stephen Hahn writes: > > > > (In John's example, star poses no conflict > > > > > > Actually, it does. I don't necessarily agree with him, but Joerg has > > > good reason to want 'star' to be /usr/bin/tar. > > > > In the interests of having a finite discussion, I must point out that > > this case, /usr/gnu, has nothing to do with implementation > > replacements like the example above. It proposes no replacements and > > in no way modifies the responsibilities of subsequent projects that > > wish to replace any individual implementation. > > I think you're missing the point I was trying to make, because I > didn't intend to refer _only_ to replacement. One alternative to > blasting star atop /usr/bin/tar is to have a /usr/schilly universe, > along with the /usr/gnu, /usr/ucb, and other universes. > (Multiverses?) > > In the 'schilly' universe, unadorned 'tar' is star.
Ah. I did indeed miss this point. I suppose my question, in parallel (the traditional adjective for universes) to "why are we doing this?" is, why would a consolidation choose to introduce a universe? In the case of /usr/gnu, it's because there is a lot of software that expects this collection to be present on the system and because there are OpenSolaris communities or consolidations that are paying an ongoing cost of its absence. Can other universes show an equivalent benefit? (My opinion is that a few, superior variants should be exploring the prefixed-addition or blast-into-place paths. You must have a significant conflicting collection to be a universe...) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
