>> However, it's not recommended that they install their versions into >> /usr/php5 or /usr/perl5 since those are OpenSolaris directories. >> Effectively unbundled software should be installed by users in some >> other place in the file system such as /opt. > > Why? These components /ARE/ effectively unbundled. We are not > really 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.
I don't agree - the actual code changes are packaging and a small set of patches to make things work on OpenSolaris (and again to reiterate, those patches are being shipped upstream). Although these changes are small, they're coupled with a hopefully intelligent management of interfaces. The intent of bundling AMP technology into OpenSolaris via the SFW consolidation is to provide a framework that others can build on. That framework may well not match the expectation or needs of certain customers and they're free, of course, to add their own versions under /opt (just like they're able to add a different versions of GNOME or sendmail or whatever under /opt or /usr/local). > Your argument makes sense for a distro - Sun probably does not wish > to have its customers randomly update its Solaris distro, but we are > talking here about OpenSolaris, where there is a need to be able to > refresh and redeliver these components as the upstream source evolves; > how can developers and users who need a later version take advantage > of this work?. One of the reasons for following the Perl directory structure was to allow these components to evolve with the upstream. However, that evolution in that directory structure should be through the OpenSolaris process and not having random users replacing bits of infrastructure. dsc
