> This isn't even an argument to put duplicates of everything into the
> /usr/gnu/bin directory.  The senario of downloading from sourceforge
> and ending up with a newer copy of everything in /usr/gnu, leaving
> the copies in /usr/bin untouched seems like the best possible result
> to me.  You've completely updated /usr/gnu and people who have
> it in there paths and left the system versions in /usr/bin unchanged.


I thought about this last night as I was playing chauffeur for our
kid's school functions (lots of waiting...)

When I wrote that, I wasn't thinking about the user downloading
the gnu utils from sourceforge and replacing them; rather, I was thinking
about the 140,000 other projects out there that are mostly under our
radar - the ones we will never add into OpenSolaris, but that users
want to use.

But, your comment struck a chord - I am in the midst of installing a
new system with B56, and the Apache httpd/Tomcat that comes with it is
slightly out of date and not configured with the modules I need.  This
means that I'm trying to do exactly what you said.

This leads me to believe that we need a different mechanism for
incorporating these OSS bits into [Open]Solaris.  Instead of forking
a copy, massaging it privately, stuffing it into a SUNW* package and
shipping the binaries with a Solaris distro, we should investigate
how to push the packaging and delivery out and up.

The best of all worlds would be for me to be able to go to the apache
download site, grab the apache httpd source, type in the configure/make
mantra and end up with a newer version of the OpenSolaris Apache Httpd
package, one that could be used as an upgrade for the one shipped with
the Solaris SX distro I am using.  Same for the GNU toolchain, etc...

This implies that the OSS stuff should not be packaged in the traditional
SUNW* packages (which imply Sun control), but rather OSOL* or even
APACHE* ones.

It also suggests that there should be a continuing Project on
OpenSolaris.org for each and every OSS thing that we decide needs
to become a part of OpenSolaris, and that these project's deliverables
are the upstream creation and maintenance of this package glue.

Of course, such an effort also needs to figure out its relationship with
the OSS things that are not part of OpenSolaris, but are delivered as part
of the Blastwave, SunFreeware, SFW and Companion CD efforts.

   -John

Reply via email to