I don't see how providing this method of managing environments would stop someone or interfere with someone using a different package which basically does the same thing. Don't we have numerous different shells which do the same basic functionality but it provides choice to the user?
Bruce On Aug 24, 2009, at 1:50 AM, Garrett D'Amore wrote: > Joep Vesseur wrote: >> On 08/21/09 22:31, John Fischer wrote: >> >> >>> This project proposes to integrate the Environment Modules within a >>> Minor release of Solaris (i.e., Open Solaris). The environment >>> modules >>> provides an easy modification to a user's environment via TCL >>> scripts. >>> These scripts set various environmental variables such as PATH, >>> MANPATH, >>> etc. >>> >> >> I'm not sure my remarks make any PSARC sense, but since there is no >> rationale mentioned for integrating this, I'm inclined to ask anyway: >> >> Does it really make sense to force people into being able to read/ >> write TCL in order for them to configure their shell? I imagine >> that most of the modulefile(4)s would be written by administrators >> (how many of them speak TCL?), but users will have to debug/override >> any settings they want to tweak. >> >> I'm just wondering why we pick a TCL-based configuration tool for >> something like this. If the answer is Linux-compatibility, I think >> there is enough precedent, whether I like it or not. Otherwise, I'm >> not sure that we build a useful architecture here. >> >> Joep >> > > I'm fairly confident that *except* in so far as we are integrating > something which some sites or projects might already be using (and > hence are offering it as a compatibility/familiarity tool), this > case would not otherwise be ready for PSARC to vote on... I think > we'd want to have a lot more scrutiny over a change intended to > fundamentally alter the way user environments are managed. > > So, as a Linux familiarity tool (and I have to take the word of > others here that this tool really is used by enough folks to make > our time spent on this case worthwhile), I'll give it a +1. > > However, I'd have much more grave reservations about making this > case a precedent setting case for the fundamental way user > environments are managed (or that we recommend they be managed.) > > I still remain, at a fundamental level, unhappy that we have no way > of distinguishing to our users, or to our ISV partners, which > technologies we believe are fundamentally architecturally correct > and "first class", and those technologies which we integrated simply > to make us conform more closely to Linux (and which we might elect > to steer users and ISVs away from.) But unfortunately at present we > have no framework to provide this information to the people who need > it most. > > -- Garrett -------------- next part -------------- Bruce Rothermal Email: bruce.rothermal at sun.com Skype: bruce.rothermal Google Talk: bruce.rothermal at gmail.com
