John Plocher wrote: > >> 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.
That is a lot of overhead in terms of projects to track and keep running and I don't believe that model scales well. An alternative might be to construct a single project that is responsible for keeping 3rd party projects "up to date" and within that project to be able to delegate responsibility for a single package to various individuals so that the workload can be spread out to those that are interested. This is the structure that FreeBSD/NetBSD use and it allows them to deliver a tree of Makefiles and information files (patches, meta data, etc) that allows you to type "make" and build the package. It has allowed them to scale their delivery of 3rd party OSS into the 100s of individual titles. Darren p.s. has this digressed far enough to be off-topic?
