> From: lvirden@... (Larry W. Virden, x2487)
> Someone using Solaris build Module packages for each of the Solaris
> install packages that are freely available, and talk to Ousterhout
> to get him to promote the stuff inside of Sun as a cost savings to
> the folk there.
A few years back, John Furlani attempted to get Modules adopted
by SunIR (our internal IS group) It didn't work, we use a home
grown Depot style setup which isn't nearly as nice. Getting it
into something like base Solaris would be considerable effort.
Fortunately, there are better methods of getting Modules to the
> Build a Solaris loadable package for Modules and submit
> it to the freely distributable Solaris package archive.
I actually did that years ago when I was at Auburn. There is a
package that loads /usr/modules to be the default setup complete
with init scripts. The main modulefile directories were automounted
under /usr/local (== /opt/local) The idea was that if /usr/modules
didn't exist, then the user would get a very basic path and an
error message would be printed that the support staff understood.
Since I put the package in the jumpstart script, that never really
happened :-) If the network or servers were down and /opt/local
wasn't available, they would still be left in a Modules environment
with a suitably default path (no network dependencies) This allows
one to login and do *something* without being stuck because of a
path dependency on /opt/local.
Anyway, packages are easy to do. Perhaps someone still at Auburn
> Perhaps even share what you can of the various other packages that
> have been built for common Solaris vendor packages like Frame, OpenWindows
> X11R6, etc. Oh - build some packages for the default Solaris 2.5 environment,
> with a CDE package, SPARCworks, Java, etc. Folks are going to start
> moving to 2.5 faster and faster - if the environment is there, and advertised
> as making it easier to upgrade, you will get their attention.
> The easier it is for a system admin to 'plug and play' support for
> things like Lotus, Excel, WABI, or whatever, the more likely they are
> to use it - anything that makes their job easier is going to be considered.
Yes. This could easily be rolled into a package. Ideally, each
application would come with it's own Modulefile, but that is a pipedream.
Heck, many ISVs still don't use packages :-(