sol11x86 at comcast.net's mail got dropped by the filters on opensolaris-arc, so I'm resending it. If you respond to this message, please make sure that all the recipients in the original have been cc'd.
mike ------- Forwarded Message Date: Wed, 28 Mar 2007 01:34:30 +0000 From: [email protected] Subject: Re: PSARC/2007/168 Including PHP5 with Solaris To: Nicolas Williams <Nicolas.Williams at sun.com> Cc: opensolaris-arc at opensolaris.org X-Mailer: AT&T Message Center Version 1 (Oct 4 2006) -------------- Original message ---------------------- From: Nicolas Williams <[email protected]> > On Tue, Mar 27, 2007 at 10:17:33AM -0700, Ben Taylor wrote: > > > Why? These components /ARE/ effectively unbundled. > > > We are not ally adding any value to this stuff as it passes > > > thru; it is the packaging and design pattern is what is important. > > > While we all wish to make them part of the default install for all > > > the OpenSolaris distros, these components are certainly not things > > > for which we (the OpenSolaris community) are the primary content > > > drivers or owners > > > > Bloat for one. /usr has become the dumping ground for all things. > > Too bad. Bloat happens in part because folks develop new things, new > things that others want, and in the development process we end up with > multiple versions of those things and multiple consumers using a variety > of versions of those things. Don't get me wrong. I'm all for Solaris getting new features. We have historical decisions that have been in effect for years (perl, apache) that we have to live with. I was merely suggesting a more sane approach to the throw everything in /usr herd mentality I've been seeing recently. > Bloat is probably unavoidable here. /usr or /opt makes little > difference -- bloat is bloat and there it is. And /usr is friendlier: > you'll find default versions of tthe bloat that you want in /usr/bin/. I think it makes a lot of difference. If it wasn't such an issue, wouldn't have /usr/ucb and /usr/xpg5 been collasped into /usr/bin by now???? Collasping more crud into /usr/bin means that I will no longer be able to have more of a Solaris "feel" rather than a GNU feel. This is going to create a horrible mess with Solaris 11 with folks doing development on Solaris 10 since the dependency trees will be completely different. > > Instead of using /opt as a place for a repository for code that is *not* > > necessary for standard operations of Solaris/OpenSolaris. The pollution > > of /usr is just staggering. And we didn't learn from the mistakes of > > moving gnome out of /opt/gnome (in the 2.0beta 3) into /usr (2.0FCS), > > and continue to dump more unnecessary (but useful) crud there. > > But as we've seen with Perl and Apache already, when some bit of bloat > becomes sufficiently widely used and demanded we'll end up moving it to > /usr anyways. I don't remember perl or apache ever being anywhere *but* /usr. > AMP *is* widely used and demanded, therefore it belongs in /usr. yeah, but there are 200 other packages that *don't* belong in /usr > > > IMHO, any software package that is a dependency for some other > > package (like apache 1.x needed for webex or whatever depends on it) > > probably has some value in being in the /usr file system. But anything > > else really ought to be in /opt, so it can be isolated, or just plain > > left out. If folks can't figure out how to use a PATH variable, then > > I think we are just making our path down the Open Source road > > more difficult as more and more gnuish/OSS stuff is just part of /usr/bin > > (or /usr/gnu, or /usr/sfw) > > Location on the FS doesn't have much to do with whether you can leave > something out of an install. Sure it does. Not only would having GNU sotware in /opt/gnu, (As an example) it would be very clear which packages are GNU. With the current trend, if I want GNU software off my system (Say I'm building my *own* tree of GNU software), it's going to be scattered all over the file system (/usr/bin, /usr/gnu, /usr/sfw, /usr/*****). Course, the call of bloats to be just like every other disorganized distro out there is just too much for the Ivory Tower types to resist. They obviously haven't bothered to port some Open Source software to Solaris with a mix of Solaris and OSS tools. Being able to select very specific "profiles" via PATHing can help correctly build Open Source software with minimal effort. This glomming of stuff into /usr/bin is going to 1) make it impossible to run a "looks like solaris tool chain" from a "looks like open source/gnuish tool chain", 2) creates a hideous dependency of tools that are part of Solaris, but are *not* required for Solaris, and even more difficult to "replace". > And as we see with AMP technologies, everything eventually becomes a > dependency of something else as people build new abstractions on > existing technologies. Do we want to move things from /opt to /usr as > they become dependencies of other things? Give me a break. We're talking Apache, MySQL and Perl, two of which have been around on Solaris *for* years. That's 3 applications out of how many freeware packages that are part of the Solaris Distro? You make it sound like there are 70 packages that *HAVE* to be in the /usr file system, or there's been a huge rush of new software that has to be in the /usr/ file system. > I think there's just no way to resist the pressure to put everything we > bundle in Solaris/OpenSolaris into /usr, at the very least commands in > /usr/bin. Obviously, there's no sense in arguing with the Ivory Tower who can't understand what a completely disorganized and irresponsible response to a requirement for more compatiblity and feature sets this path takes Again, I am just shocked that segemented directories, with smart PATH'ing isn't enough, but I guess the public is just too dumb to understand how to separate out groups or styles of tools, without having every tool known to man in one *flippin* directory. I guess it's a matter of time before /usr/bin becomres /windows. > The serendipitous discovery case can be seen (IMO) as > acknowledging the "every bundled thing into /usr/bin" (and therefore > partially or completely into /usr) approach. I guess I can't really expect anything more since we haven't been able to build a decent set of user profile start scripts in the 15 years I've been using Solaris. Glom everything into /usr/bin, that'll make it all ok. > Because users discover > things in /usr/lib too (though autoconf configure scripts and the like) > the same principle should probably apply to libraries, not just > commands, leaving us very close to an "every bundled thing into /usr" > approach. Why doth I protest too much? Cause I've been using Solaris for 14 years. And this rush to get everything open source and gnu like every other *inux and *bsd distrbution into /usr is as poorly a thought out idea as I've ever seen. If I want Solaris, I want Solaris. If I want Solaris/Gnu, I can path it that way. The road we're heading down leaves me one of three options 1) run Solaris 10 into the ground 2) deal with Glomaris 11 3) start my own Open Solaris Distro. Least I have 14 years of porting experience should I decide to follow that route. And that distro would have at least 3 distinctive feels/profiles to it....
