Sriram Natarajan wrote: > > > >Elaborate a bit more on what each package does. I'm assuming each > >package delivers > > /usr/php/5.2/modules/foo.so and > > /etc/php/5.2/conf.d/foo.ini > >such that installing the package automatically enables that extension > >(after the next restart of PHP). > > > >True? > >Any exceptions to that behavior pattern? > > > That is the expected behavior. No other exceptions to this (at this point.)
In s.2.8 of the revised spec, be a little more specific in explaining the info above. Remember the future readers of this document are not necessarily familiar with PHP so being detailed always helps. I suggest adding between 2nd and 3rd paragraphs of s.2.8: Specifically, each SUNWphp52u-$MODULE package will deliver the files: /usr/php/5.2/modules/$MODULE.so /etc/php/5.2/conf.d/$MODULE.ini > >> We propose to drop bundling 'dtrace.so' within SUNWphp52u > >> package. This extension has been rolled into PHP engine itself. > >> So, there should be no loss of functionality with this change. > > > >Do users have to care about this detail? As long as customer's > >existing dtrace scripts continue to work as-is (modulo the one rename > >noted above), is there a customer impact on whether the implementation > >lives in dtrace.so vs. baked into the main binary? > > It should not matter to customers. They should not know where the probes > are coming from. In that case you can remove section 1.1b as it is not of architectural significance where the implementation details live. Mentioning it passing as you do in s.2.8 is sufficient. > These 3rd party extensions may not life for a long life unlike the case > with regular PHP distribution. These are bundled for convenience sake. > Hence, I am hoping to catch them with Volatile. Is it really likely that all these extensions will disappear during PHP 5.2.* lifetime? (It is ok for ARC if the answer is yes, but because that's a fairly surprising answer, it needs documenting some supporting evidence for that prediction.) Some more comments in the next email. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems