Stephen Hahn writes: > * James Carlson <james.d.carlson at sun.com> [2006-04-28 14:10]: > > Stephen Hahn writes: > > > 1. Must /usr/gnu be a subdirectory of /usr, or can it be a separate > > > filesystem? > > > > It'd be simpler there. But any place would probably do. > > A different degree of freedom than I meant: I was trying to figure > out whether the g* tools in /usr/bin could be hard links, or not.
Oh. I guess I don't see a great deal of difference; it seems like a detail to me. > > Ouch. The other key question related to that is the operation with > > zones. A sparse zone will inherit /usr and thus get a read-only copy > > of /usr/gnu -- meaning that every zone has the same tools as the > > global zone. Perhaps not what was desired. > > So separate filesystems should be allowed, even if the default > configuration doesn't do so. That means /usr/gnu becomes a famous mount point, just like /usr/local. I suppose it's somewhat reasonable, though I'm not entirely sure why I'd want that. (Meaning: I can always hack my system to work the way I want it to, but forcing others to factor their packages to suit me seems like a stretch.) > > The multi-version question is just plain ugly, because some tools have > > non-trivial (and incompatible!) configuration file formats. Having > > multiple versions at once means solving those problems as well. > > Okay: one version model. Delivering multiple versions is left to the > site to figure out. What I neglected to say is that multiple versions may well be a _requirement_, but one that's hard to satisfy. Version-per-zone is probably feasible, though squirreled-away reference data files or internal libraries can be a problem. And, clearly, having a version level per utility is really tough. I'm not sure that it ought to be a "pick your favorite version levels of these items" sort of interface, but that's the slippery slope that the /usr/java symlink has introduced. (To my mind, allowing version choice is rather counter to rational system architecture. But I know that others think differently.) > > (Maybe a `uidfs' would solve it. It mounts on /usr and each user gets > > to pick and choose the objects he wants to see in /usr/bin. Just > > kidding. Really. ;-}) > > I like it! I was worried about that. ;-} I think the project to implement it should be dependent on implementing setpid(2) as well, for complete flexibility. > > They're sometimes handy for users who want to stay in a traditional > > UNIX environment and occasionally grab GNU-ish tools (with > > /usr/sfw/bin or /usr/gnu/bin or whatever at the _end_ of the $PATH), > > but that handiness isn't very substantial. I don't need "ups" for > > /usr/ucb/ps, so I probably don't need "gps" for GNU ps. > > So, one rule would be "if we or another operating system has a > commonly known g* variant for this tool, we will ship it as well; > otherwise, not shipped". Yes, that's something like what I'd propose. I'd more likely just say "no g* variant required by default, if you want one though, then explain." There are bound to be imaginative reasons in the future do something like that, and attempting to prescribe how to use it (except perhaps as an example rationale) probably isn't required. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
