On Mar 26, 2007, at 11:57 AM, James Carlson wrote: > Stefan Teleman writes: >> The PHP Group has *no interest whatsoever* in Solaris. This may >> change in the >> future, but it is highly unlikely to change within a predictable >> timeframe. > > Perhaps there's a miscommunication here.
Well, certainly one miscommunication, since Stefan is not part of the PHP Group and therefore has no idea what he is talking about in regards to the thousand-plus opinions that might influence a single PHP release. I am quite certain that at least one of those people care about Solaris as a platform for PHP. It is quite possible, though, that the proposed changes to PHP are simply brain dead, even for Solaris, and the only way to find that out is to participate in the PHP development process. Personally, I think the case should be derailed and the project should proceed after it has discussed with the development projects concerned what they would like to see in a Solaris default installation. For example, with my VP Apache HTTP Server hat on, I would prefer to have each of the components installed in a way that they can be reused consistently by third-party deployments. That means APR-0 and APR-1 are installed on their own, as shared libraries with separate include and build artifacts (necessary for other components that will use those artifacts for their own build process), in both 32bit and 64bit forms. But I am only one of the two dozen or so core HTTP Server developers, so you might get a better perspective by discussing it on one of the Apache mailing lists (dev at httpd.apache.org / dev at apr.apache.org). A little open discussion on the right list will save you a huge amount of breakage in the future. Alternatively, decide that Solaris is interested in a specific set of features that Solaris itself uses, and install a specific platform under /usr/www to support those given features. There is no need to call it the apache2 install, just as cups does not call its own copy of Apache httpd the apache install, and no need to support more than one platform ABI within the scope of that particular tree. On the grander scale of "how to install a framework", I would suggest looking at the Frameworks in OS X. They are essentially the same as the JRE style installations and, though that is indeed a hassle in many ways, it has been proven as a mechanism for installing multiple ABI installs of a single product without losing too many customers. Today's hard disks are big enough that installing multiple copies is far more cost efficient than either one of living in the past or bleeding on the edge. ....Roy
