John, > Furthermore, I would like to see the build/config changes that support > such a design pattern pushed back upstream to the various component > owners such that anyone could download a newer version of the component, > build it, and install it along side whatever existing versions were > already there. In the best of all worlds, one would be able to exactly > rebuild any of the existing versions as well, making it easy to confidently > tweak/optimize the component for site specific needs.
All of the build/config changes for open-source components like this are made available - either today through source packages and in the future, through a SCM that supports tagged snapshots. This has always been the case. As to pulling our source and making changes to a newer version that is downloaded upstream, it's certainly possible for someone to do so. 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. The one "exception" that I believe we make with components like Perl and can make with PHP too is that the symbolic link /usr/bin/<whatever> can be replaced by the user to point to their own version of the component. That's why components shipped with Solaris itself tend to not reference the generic name but rather a versioned name (see `head -1 /usr/bin/kstat', for example). dsc
