Alias problems emails must still be awaiting moderator approval. There is one command modulecmd which is covered in the man page module.1
Modulefiles are covered in the modulefile.4 man page. Bruce On Aug 25, 2009, at 9:28 AM, Garrett D'Amore wrote: > I've not seen an answer to my questions/concerns, which I posted > elsewhere (on the alias with the case number so that it will go to > the case log.) The questions involve the concern about building Sun > software on top of this, and insisting on additional review (because > its no longer a familiarity case, but deserves first class review), > the appropriateness of Tcl (for a couple of reasons), and issues > with adequate interface specification (the modules file syntax and > commands needs to be part of the review.) > > -- Garrett > > Bruce Rothermal wrote: >> There has been numerous mentions about OpenSolaris vs. Solaris.next >> and /release and /contrib. That OpenSolaris belongs to the >> community whereas Solaris is controlled by Sun. I really don't much >> care if this package is in Solaris but I do need it in OpenSolaris. >> So from my experience I only know of this one path offered to get >> packages into OpenSolaris's /release repository and that is to go >> through a Solaris consolidation. If anybody knows of some other way >> I would like to hear it. So far all I'm hearing is a bunch of >> philosophying. Is there anything technically wrong or harmful about >> this package. I have a task assigned to port this package for a >> project to create a product which we intend to sell and make money >> for Sun. I don't see what the fuss is. It is a simple layered >> application which helps the user, should they want to use this, to >> manage some environment for a project. I don't see anything in this >> that makes it mandatory, compulsory or in any way changes the >> Solaris or OpenSolaris architecture. Nothing about Environment >> Modules is started automatically or done hidden. >> >> So please advise if there is a different process for getting this >> package into OpenSolaris /release repository or for that matter how >> this simple little application will be destroying the Solaris/ >> OpenSolaris architecture? >> >> Bruce >> >> >> On Aug 25, 2009, at 1:23 AM, Milan Jurik wrote: >> >>> Hi Mark, >>> >>> Mark Martin p??e v po 24. 08. 2009 v 17:00 -0500: >>>> Nicolas Williams wrote: >>>>> On Mon, Aug 24, 2009 at 07:02:18PM +0200, Milan Jurik wrote: >>>>> >>>>>>> Another question that may arise is the architectural status >>>>>>> of /contrib >>>>>>> (e.g., can the ARC bless integrations into /contrib in some >>>>>>> manner that >>>>>>> confers, say, protection to filesystem namespace camping in / >>>>>>> contrib? >>>>>>> do interfaces in /contrib have to advertise stability >>>>>>> attributes? >>>>>>> etcetera). >>>>>>> >>>>>>> IMO: Integrate it all, and let users sort it out (a paraphrase >>>>>>> of a >>>>>>> Spanish inquisitor quote) (e.g., with a voting scheme). If an >>>>>>> i-team can't commit to interface stability, then make all >>>>>>> public >>>>>>> interfaces Volatile, and mark the package as "toxic interface >>>>>>> stability", see if users still want it :) >>>>>>> >>>>>>> >>>>>>> >>>>>> And who will sustain such thing for the next 10+ years? ARC is >>>>>> looking >>>>>> at effectivness Sun Engineering resources. Pushing something to >>>>>> repository does not mean end of issue, it is the cheapiest thing. >>>>>> >>>>> >>>>> >>>> 1) Any comment or opinion regarding /contrib or /release or >>>> "OpenSolaris" will be based on an effort that has had little or no >>>> direct ARC interaction. >>> >>> That's the question. What's ARC responsibility? Only "API" between >>> bits, >>> or also the whole product architecture? From my understanding >>> there is >>> small problem - OpenSolaris distro is Sun thing (it's Sun decision >>> what >>> will be there), but OpenSolaris project is community thing. As I >>> wrote, >>> if ARC will be deciding about /contrib vs. /release, it will remain >>> Sun-centric (other distros can have and have other oppinions). >>> >>>> On the one hand, it IS the elephant. On the >>>> other hand, it's SMI's elephant. >>> >>> I agree, it's Sun elephant. But not only. "Sustaining" does not mean >>> only Sun support/bugfixing of Sun distro. It means also that all >>> other >>> projects going to the selected consolidation will need to take care >>> about the integrated project. Mainly in case of SFW consolidation. >>> And >>> such resources are not only Sun Engineering. But yes, it is mostly >>> Sun >>> problem. >>> >>>> What *is* /contrib? I know what Sun's >>>> marketing says it is. Is that the only source of information >>>> with which >>>> to qualify it and appropriateness for considering it as an >>>> approach to >>>> integration and deployment? How much speculation need we endure >>>> here? >>>> >>>> 2) This has been brought up several times before. I don't see >>>> anything >>>> really happening here until there are dollars behind it, or some >>>> serious >>>> direction from SAC or other technical management. But maybe that's >>>> paint you're referring to in the subject? >>>> >>> >>> I think I have no more to add here. >>> >>>> If you're serious about this, and #2 notwithstanding, I've got an >>>> ARC >>>> case started a few weeks ago where I intended to review our >>>> stability >>>> taxonomy in the light of today's world with: OpenSolaris(tm) here >>>> today, >>>> Solaris.Next(tm) around the corner, efforts to grow a nascent >>>> porting >>>> community, these things called IPS repositories, other software >>>> repository ecosystems (Glassfish's update center, Netbean's update >>>> center, Eclipse's update center), etc. >>>> http://arc.opensolaris.org/caselog/LSARC/2009/316/ >>> >>> I and serious? Never :-) Thank you for pointer. I will follow this >>> case. >>> >>> Best regards, >>> >>> Milan >>> >> >> >> >> Bruce Rothermal >> Email: bruce.rothermal at sun.com >> Skype: bruce.rothermal >> Google Talk: bruce.rothermal at gmail.com >> >> >> >> > -------------- next part -------------- Bruce Rothermal Email: bruce.rothermal at sun.com Skype: bruce.rothermal Google Talk: bruce.rothermal at gmail.com
