James Carlson wrote: > Kyle McDonald writes: > >> The Symlink package, fixes all of this. utilities will be at a known, OS >> controlled location for other packages to depend on, Can be found in >> /usr/bin on systems where that is desirable, and can be overridden by >> admins and/or users who know and want to. >> >> It seems to me that the only downside to the symlink package is that it >> uses symlinks. >> > > You're missing at least two downsides that've already been discussed: > > - The behavior of the system for ordinary users depends on whether > the administrator has installed this special package. Thus, users > are (at least to some degree) beholden to administrators to set up > their environment. > > Then you better not let them choose to not install the /usr/gnu packages also.
I don't see this as a downside. Coming from an administrator background, I'd feel responsible to give the users what they need at my site on my set of machines. And I'd demand the flexibility to do so. I don't think that anyone working on solaris can really beleive they'll know better than the administrators of a site what's best for the user community at that site? > - The behavior of Solaris systems ends up being uneven. Some will > install the package, some will not. Users who must move between > these systems will be confused, and their $PATH configurations > will have different effects on each. > > For users who we are successfully hiding the existence of $PATH, as long as the administrator (or the defaults) allow them to do what is supposed to be allowed at that site, then I don't see a problem. These users are not going to be interested in moving .dotfiles around between sites - and if they do I don't think should have the expectation that they'll just work. For users who know about .dotfiles, and $PATH, they shouldn't expect to be able to move them without changing them. Is this really the problem we're trying to solve? -Kyle
