Stephen Hahn wrote: > * 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? > > I agree. In the interest of keeping things organized, and having things be found where users might expect to find them from the directory names, I'd think that all things belonging to a 'universe' would be located together. I'd hate to try to explain to someone why some Gnu things are found in /usr/gnu (logical place to think it would be once you know /usr/gnu exists) and others are given preferential treatment and promoted to /usr/bin. Why create confusion?
Something (possibly minor) that I think hasn't been stated yet, is that makes the whole universe switchable on and off. It allows the user to pull the whole thing in, or nothing. Some may say there is no harm in having things available to you (as long as ther are no conflicts) when you would never type them in. But I do know users who want there 'command namespace' as unpolluted as possible. One reason is commandline completion. Once enough things are on your PATH, command completion becomes next to useless. I concede that it's desirable to have new users find this stuff by default. And it appears that updating PATH (even in user or admin 'undoable' ways) is out of the question, then that leaves the option of a OS maintained symlink set to pull things into /usr/bin that should be visible by default. Removing the GNU tools at the package level entirely from the system, has the problems of possible package dependencies, and that it affects all users. Removing the Symlink package would not have this problem. > (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...) > > Yes I wouldn't want to 'see' universes created for few commands. This is where naming your universe and setting it's scope becomes an issue. > - Stephen > >
