From bart.smaalders@Sun.COM Tue Mar 20 21:07:11 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2L47A5Y016389 for ; Tue, 20 Mar 2007 21:07:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2L478wG027088 for <@sunmail1brm.central.sun.com:PSARC-EXT@Sun.COM>; Wed, 21 Mar 2007 12:07:08 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF800M01JFV3W00@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 22:07:07 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF800H8BJFUTZ80@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 22:07:06 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2L476tX003563; Tue, 20 Mar 2007 21:07:06 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2L475TF029538; Tue, 20 Mar 2007 21:07:06 -0700 (PDT) Date: Tue, 20 Mar 2007 21:06:14 -0700 From: Bart Smaalders Subject: PSARC/2007/168 Including PHP5 with Solaris To: PSARC-EXT@Sun.COM Cc: Stefan Teleman Message-id: <4600AF36.8080407@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xe41hCusKAYzBuVOEgwXjQ)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 23419 This is a multi-part message in MIME format. --Boundary_(ID_xe41hCusKAYzBuVOEgwXjQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I'm sponsoring the attached fast-track for Stefan Teleman. The requested binding is patch/micro release, and the stability levels are as noted in the document. Materials are in the case directory. This case times out on 3/28/2007. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts --Boundary_(ID_xe41hCusKAYzBuVOEgwXjQ) Content-type: text/plain; name=PHP5FastTrack.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=PHP5FastTrack.txt Including PHP5 with Solaris Stefan Teleman 15 March 2007 1. Summary and motivation The inclusion of PHP5 in Solaris as a component of SAPP [Solaris, Apache, PostgreSQL, PHP] will address a current shortcoming of SMI's software portfolio. The absence in Solaris of a LAMP [Linux, Apache, MySQL, PHP] equivalent software stack has allowed Linux to create the perception that it is the operating environment of choice for web-based applications. This case seeks Micro/Patch Release Binding. 2. Technical issues 2.1. Key objects. /usr/bin/php /usr/bin/php-config /usr/bin/phpize /usr/lib/libphp5-5.2.0.so /usr/lib/libphp5.so -> /usr/lib/libphp5-5.2.0.so /etc/php5/php.ini All other objects will be contained within the /usr/php5/[version] hierarchy. This hierarchy will loosely track that of the publicly available version. The current version of PHP5 [5.2.0] is 64-bit clean and largefile aware. A 64-bit version of PHP is being considered for a future release. 2.2. Versioning The PHP5 development process follows the ubiquitous "continuous development" model, typical of many Open Source projects. Currently, two Releases of PHP coexist, and are still under development: PHP4 and PHP5. Also, PHP6 is currently under active development, and is scheduled to be released sometime during 2007. None of these three Releases make any guarantees of API and ABI compatibility. The PHP versioning model has followed the .. model. The version of PHP5 proposed for inclusion in Solaris is PHP 5.2.0. 2.3. Directory Naming and Structure The proposed directory layout for PHP5 is: /usr/php5/ bin -> [version]/bin doc -> [version]/doc etc -> /etc/php5 include -> [version]/include lib -> [version]/lib man -> [version]/man modules -> [version]/modules share -> [version]/share The detailed directory and file layout for PHP5 is provided in Addendum 1. 2.4. Packaging and Delivery The current proposal allows for the inclusion and coexistence of multiple versions of PHP by keeping each installation under a version-specific subdirectory. The following package naming convention is proposed: SUNWphp520root SUNWphp520core SUNWphp520usr SUNWphp520man SUNWphp520doc SUNWphp520root will deliver only one file, the system-wide PHP5 configuration file: /etc/php5/php.ini SUNWphp520core will deliver the minimal filesystem objects for a functional PHP5 Apache installation: SUNWphp520core: /usr/php5/etc -> /etc/php5 /usr/php5/[version]/lib /usr/php5/[version]/modules /usr/php5/lib -> /usr/php5/[version]/lib /usr/php5/modules -> /usr/php5/[version]/modules SUNWphp520usr will deliver the additional userland and developer filesystem objects: SUNWphp520usr: /usr/php5/[version]/bin /usr/php5/[version]/include /usr/php5[version]/share /usr/php5/bin -> /usr/php5/[version]/bin /usr/php5/include -> /usr/php5/[version]/include /usr/php5/share -> /usr/php5[version]/share SUNWphp520doc will deliver the full and complete PHP5 documentation in HTML format. SUNWphp520man will deliver the available man pages for PHP5: /usr/share/man/man1/php.1 /usr/php5/[version]/man/man1/php.1 /usr/php5/[version]/man/man1/php-config.1 /usr/php5/[version]/man/man1/phpize.1 /usr/php5/man -> /usr/php5/[version]/man 3. PHP5 Modules [Extensions]. PHP supports a loadable module interface (known in PHP parlance as "Extensions"), allowing the PHP runtime to communicate with, and bind to, external interfaces. This module interface also allows for the clean integration of new PHP features or bindings. In addition, SMI may want to provide customers internally developed PHP Extensions. PHP Extensions have an associated dynamically loadable shared object (*.so). As mentioned earlier, PHP makes no guarantee of binary compatibility between releases. Maintaining PHP within the constraint of such possible binary incompatibilities motivates the directory layout structure proposed in 2.3. 3.1. PHP Core Modules. The initial integration will provide a subset of the PHP5 Core Extensions as delivered by the canonical PHP5 Release: pcre [Perl-Compatible Regular Expressions] idn [International Domain Names Resolver] gd [Graphics Device] exif [EXIF Metadata Information] psql [PostgreSQL bindings] mbstring [Multi-Byte Strings/UTF Encoding bindings] gettext [GNU-compatible gettext binding] iconv [GNU compatible character encoding/conversion bindings] xml [XML bindings] pdo [PHP Database Objects bindings] pgsql [PostgreSQL bindings] soap [SOAP bindings] spl [Standard PHP Library] ssl [OpenSSL bindings] tcpwrap [TCPWrap bindings] tidy [HTML parsing and validation library] zlib [libz compression bindings] bz2 [libbz2 compression bindings] zip [libzip bindings] json [JavaScript bindings] bcmath [Binary Calculator Math bindings] calendar [Calendar bindings] ctype [Character bindings] curl [C-URL bindings] dom [DOM XSLT bindings] posix [POSIX bindings] sockets [libsocket bindings] session [PHP Session bindings] suhosin [Hardened PHP Extension] apc [Advanced PHP Caching Extension] Additional Extensions can be delivered subsequent to the initial PHP5 integration, depending on customer requests, and on the availability of the external dependencies required by these Extensions. 4. PHP5 Internationalization. PHP5 provide basic I18N support via its ctype/gettext/iconv/mbstring Extensions. As an externally developed application, PHP5 will not provide additional Internationalization support beyond what is provided by the canonical distribution. 5. PHP5 Documentation. PHP5 comes with an exhaustive set of documentation available in several languages from the PHP Site [http://www.php.net/docs.php] [2]. 5.1. Full Adoption. The full PHP5 documentation is available for download from the PHP Site [http://www.php.net/download-docs.php] [3]. This documentation collection should be placed in the separate [doc] directory for each PHP5 Release [/usr/php5/[version]/doc], with an appropriate symbolic link to /usr/php5/doc. 5.2. Manual Pages. PHP5 provides a default man page [php(1)]. This man page will be delivered in the appropriate man directory [/usr/php5/[version]/man], with an appropriate symbolic link to /usr/php5/man. The contents of this man page is provided in Addendum 2. A generic man page will be delivered in the standard Solaris man directory (/usr/share/man/man1/php.1). This man page will follow the model introduced by Perl5 [PSARC 1999/192], and will provide a complete listing of available PHP5 man pages [php(1), phpize(1) and php-config(1)]. The contents of this man page is provided in Addendum 3. 6. Interfaces 6.1. Interface Stability. PHP, as an Open Source project, is controlled by a group of developers external of, and independent from, SMI. The PHP Group makes no guarantees or promises of ABI or API compatibility between PHP releases. 6.2. Imported Interfaces. NAME STABILITY NOTES Apache 2.2 APR Libraries Uncommitted PSARC/2007/000 OpenSSL [Secure Sockets Layer] External/Volatile PSARC/2003/500 PCRE [Perl-Compatible Regular Expressions] Uncommitted PSARC/2007/000 IDN [Internationalized Domain Library] Uncommitted PSARC/2007/000 GD [Graphics Device Library] Uncommitted PSARC/2007/000 EXIF [EXIF Metadata Information] Uncommitted PSARC/2007/000 PostgreSQL Uncommitted LSARC/2006/655 TCPWrap [TCP Wrappers Library] Evolving PSARC/2001/709 Tidy [HTML Validation Library] Uncommitted PSARC/2007/134 Z-lib [Zlib Compression Library] Committed PSARC/2006/537 BZ2 [bz2 Compression Library] Standard PSARC/1999/555 ZIP [Zip Compression Library] Standard PSARC/1999/555 CURL [C-URL Library] Uncommitted PSARC/2007/000 LibXML [XML Library] Standard PSARC/2001/175 LibXSLT [XSLT Transformation Library] Evolving PSARC/2002/244 LibFreetype 2 [Freetype Library] External LSARC/2005/397 LibFontconfig [Fontconfig Library] External LSARC/2003/273 6.3. Exported Interfaces. PHP5 implements two types of Exported Interfaces. The first type [Type 1] is a one-to-one mappping between a physical filesystem object, and its associated Interfaces. The second type [Type 2] is a virtual mapping of two distinct Interface Objects: a physical filesystem object and an Interface moniker handle which may, or may not act as a provider of programmatic interface(s). Not all Type 2 Interfaces provide a programmatic interface. Typically, but not always, Type 2 Interfaces which do not provide a programmatic interface, provide a configuration interface via the php.ini file. This Type 2 Interface is characteristic of PHP5's Extensions. Also characteristic of the Type 2 Interface is the property that physical filesystem object Interfaces are always Private and implicitly Volatile, whereas their corresponding programmatic, or configuration interfaces, if they exist, are public and Uncommitted. NAME STABILITY NOTES SUNWphp520core Uncommitted Package Name SUNWphp520usr Uncommitted Package Name SUNWphp520man Uncommitted Package Name SUNWphp520doc Uncommitted Package Name /usr/php5/[version]/bin/php Uncommitted Executable location /usr/php5/bin/php Uncommitted Symbolic link /usr/bin/php Uncommitted Symbolic link /usr/php5/[version]/bin/phpize Uncommitted Executable location /usr/php5/bin/phpize Uncommitted Symbolic link /usr/php5/[version]/bin/php-config Uncommmited Executable location /usr/php5/bin/php-config Uncommitted Symbolic link /etc/php5/php.ini Uncommitted Configuration file /usr/php5/[version]/etc/php.ini Uncommitted Symbolic link /usr/php5/etc/php.ini Uncommitted Symbolic link /usr/php5/[version]/lib/libphp5-5.2.0.so Uncommitted PHP Library /usr/php5/lib/libphp5-5.2.0.so Uncommitted Symbolic link /usr/lib/libphp5-5.2.0.so Uncommitted Symbolic link /usr/apache2/modules/libphp5-5.2.0.so Uncommitted Symbolic link /usr/php5/[version]/include/TSRM/TSRM.h /usr/php5/[version]/include/TSRM/acconfig.h /usr/php5/[version]/include/TSRM/readdir.h /usr/php5/[version]/include/TSRM/tsrm_config.h /usr/php5/[version]/include/TSRM/tsrm_config.w32.h /usr/php5/[version]/include/TSRM/tsrm_config_common.h /usr/php5/[version]/include/TSRM/tsrm_nw.h /usr/php5/[version]/include/TSRM/tsrm_strtok_r.h /usr/php5/[version]/include/TSRM/tsrm_virtual_cwd.h /usr/php5/[version]/include/TSRM/tsrm_win32.h /usr/php5/[version]/include/Zend/FlexLexer.h /usr/php5/[version]/include/Zend/acconfig.h /usr/php5/[version]/include/Zend/zend.h /usr/php5/[version]/include/Zend/zend_API.h /usr/php5/[version]/include/Zend/zend_alloc.h /usr/php5/[version]/include/Zend/zend_builtin_functions.h /usr/php5/[version]/include/Zend/zend_compile.h /usr/php5/[version]/include/Zend/zend_config.h /usr/php5/[version]/include/Zend/zend_config.nw.h /usr/php5/[version]/include/Zend/zend_config.w32.h /usr/php5/[version]/include/Zend/zend_constants.h /usr/php5/[version]/include/Zend/zend_dynamic_array.h /usr/php5/[version]/include/Zend/zend_errors.h /usr/php5/[version]/include/Zend/zend_exceptions.h /usr/php5/[version]/include/Zend/zend_execute.h /usr/php5/[version]/include/Zend/zend_extensions.h /usr/php5/[version]/include/Zend/zend_fast_cache.h /usr/php5/[version]/include/Zend/zend_globals.h /usr/php5/[version]/include/Zend/zend_globals_macros.h /usr/php5/[version]/include/Zend/zend_hash.h /usr/php5/[version]/include/Zend/zend_highlight.h /usr/php5/[version]/include/Zend/zend_indent.h /usr/php5/[version]/include/Zend/zend_ini.h /usr/php5/[version]/include/Zend/zend_ini_parser.h /usr/php5/[version]/include/Zend/zend_ini_scanner.h /usr/php5/[version]/include/Zend/zend_interfaces.h /usr/php5/[version]/include/Zend/zend_istdiostream.h /usr/php5/[version]/include/Zend/zend_iterators.h /usr/php5/[version]/include/Zend/zend_language_parser.h /usr/php5/[version]/include/Zend/zend_language_scanner.h /usr/php5/[version]/include/Zend/zend_list.h /usr/php5/[version]/include/Zend/zend_llist.h /usr/php5/[version]/include/Zend/zend_mm.h /usr/php5/[version]/include/Zend/zend_modules.h /usr/php5/[version]/include/Zend/zend_multibyte.h /usr/php5/[version]/include/Zend/zend_multiply.h /usr/php5/[version]/include/Zend/zend_object_handlers.h /usr/php5/[version]/include/Zend/zend_objects.h /usr/php5/[version]/include/Zend/zend_objects_API.h /usr/php5/[version]/include/Zend/zend_operators.h /usr/php5/[version]/include/Zend/zend_ptr_stack.h /usr/php5/[version]/include/Zend/zend_qsort.h /usr/php5/[version]/include/Zend/zend_stack.h /usr/php5/[version]/include/Zend/zend_static_allocator.h /usr/php5/[version]/include/Zend/zend_stream.h /usr/php5/[version]/include/Zend/zend_strtod.h /usr/php5/[version]/include/Zend/zend_ts_hash.h /usr/php5/[version]/include/Zend/zend_types.h /usr/php5/[version]/include/Zend/zend_variables.h /usr/php5/[version]/include/Zend/zend_vm.h /usr/php5/[version]/include/Zend/zend_vm_def.h /usr/php5/[version]/include/Zend/zend_vm_execute.h /usr/php5/[version]/include/Zend/zend_vm_opcodes.h /usr/php5/[version]/include/php/ext/date/php_date.h /usr/php5/[version]/include/php/ext/date/lib/timelib.h /usr/php5/[version]/include/php/ext/date/lib/timelib_config.h /usr/php5/[version]/include/php/ext/date/lib/timelib_structs.h /usr/php5/[version]/include/php/ext/dom/xml_common.h /usr/php5/[version]/include/php/ext/gd/gdcache.h /usr/php5/[version]/include/php/ext/gd/gdttf.h /usr/php5/[version]/include/php/ext/gd/php_gd.h /usr/php5/[version]/include/php/ext/hash/php_hash.h /usr/php5/[version]/include/php/ext/hash/php_hash_adler32.h /usr/php5/[version]/include/php/ext/hash/php_hash_crc32.h /usr/php5/[version]/include/php/ext/hash/php_hash_gost.h /usr/php5/[version]/include/php/ext/hash/php_hash_haval.h /usr/php5/[version]/include/php/ext/hash/php_hash_md.h /usr/php5/[version]/include/php/ext/hash/php_hash_ripemd.h /usr/php5/[version]/include/php/ext/hash/php_hash_sha.h /usr/php5/[version]/include/php/ext/hash/php_hash_snefru.h /usr/php5/[version]/include/php/ext/hash/php_hash_tiger.h /usr/php5/[version]/include/php/ext/hash/php_hash_types.h /usr/php5/[version]/include/php/ext/hash/php_hash_whirlpool.h /usr/php5/[version]/include/php/ext/iconv/php_iconv.h /usr/php5/[version]/include/php/ext/iconv/php_have_bsd_iconv.h /usr/php5/[version]/include/php/ext/iconv/php_have_glibc_iconv.h /usr/php5/[version]/include/php/ext/iconv/php_have_iconv.h /usr/php5/[version]/include/php/ext/iconv/php_have_libiconv.h /usr/php5/[version]/include/php/ext/iconv/php_iconv_supports_errno.h /usr/php5/[version]/include/php/ext/iconv/php_php_iconv_h_path.h /usr/php5/[version]/include/php/ext/iconv/php_php_iconv_impl.h /usr/php5/[version]/include/php/ext/libxml/php_libxml.h /usr/php5/[version]/include/php/ext/mbstring/mbstring.h /usr/php5/[version]/include/php/ext/mbstring/php_mbregex.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/config.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/eaw_table.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfilter.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfilter_8bit.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfilter_pass.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfilter_wchar.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_allocators.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_consts.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_convert.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_defs.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_encoding.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_filter_output.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_ident.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_language.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_memory_device.h /usr/php5/[version]/include/php/ext/mbstring/libmbfl/mbfl/mbfl_string.h /usr/php5/[version]/include/php/ext/mbstring/oniguruma/oniguruma.h /usr/php5/[version]/include/php/ext/mbstring/oniguruma/php_onig_compat.h /usr/php5/[version]/include/php/ext/pdo/php_pdo.h /usr/php5/[version]/include/php/ext/pdo/php_pdo_driver.h /usr/php5/[version]/include/php/ext/session/mod_files.h /usr/php5/[version]/include/php/ext/session/mod_user.h /usr/php5/[version]/include/php/ext/session/php_session.h /usr/php5/[version]/include/php/ext/standard/base64.h /usr/php5/[version]/include/php/ext/standard/basic_functions.h /usr/php5/[version]/include/php/ext/standard/crc32.h /usr/php5/[version]/include/php/ext/standard/credits.h /usr/php5/[version]/include/php/ext/standard/credits_ext.h /usr/php5/[version]/include/php/ext/standard/credits_sapi.h /usr/php5/[version]/include/php/ext/standard/css.h /usr/php5/[version]/include/php/ext/standard/cyr_convert.h /usr/php5/[version]/include/php/ext/standard/datetime.h /usr/php5/[version]/include/php/ext/standard/dl.h /usr/php5/[version]/include/php/ext/standard/dns.h /usr/php5/[version]/include/php/ext/standard/exec.h /usr/php5/[version]/include/php/ext/standard/file.h /usr/php5/[version]/include/php/ext/standard/flock_compat.h /usr/php5/[version]/include/php/ext/standard/fsock.h /usr/php5/[version]/include/php/ext/standard/head.h /usr/php5/[version]/include/php/ext/standard/html.h /usr/php5/[version]/include/php/ext/standard/info.h /usr/php5/[version]/include/php/ext/standard/md5.h /usr/php5/[version]/include/php/ext/standard/microtime.h /usr/php5/[version]/include/php/ext/standard/pack.h /usr/php5/[version]/include/php/ext/standard/pageinfo.h /usr/php5/[version]/include/php/ext/standard/php_array.h /usr/php5/[version]/include/php/ext/standard/php_assert.h /usr/php5/[version]/include/php/ext/standard/php_browscap.h /usr/php5/[version]/include/php/ext/standard/php_crypt.h /usr/php5/[version]/include/php/ext/standard/php_dir.h /usr/php5/[version]/include/php/ext/standard/php_ext_syslog.h /usr/php5/[version]/include/php/ext/standard/php_filestat.h /usr/php5/[version]/include/php/ext/standard/php_fopen_wrappers.h /usr/php5/[version]/include/php/ext/standard/php_ftok.h /usr/php5/[version]/include/php/ext/standard/php_http.h /usr/php5/[version]/include/php/ext/standard/php_image.h /usr/php5/[version]/include/php/ext/standard/php_incomplete_class.h /usr/php5/[version]/include/php/ext/standard/php_iptc.h /usr/php5/[version]/include/php/ext/standard/php_lcg.h /usr/php5/[version]/include/php/ext/standard/php_link.h /usr/php5/[version]/include/php/ext/standard/php_mail.h /usr/php5/[version]/include/php/ext/standard/php_math.h /usr/php5/[version]/include/php/ext/standard/php_metaphone.h /usr/php5/[version]/include/php/ext/standard/php_rand.h /usr/php5/[version]/include/php/ext/standard/php_smart_str.h /usr/php5/[version]/include/php/ext/standard/php_smart_str_public.h /usr/php5/[version]/include/php/ext/standard/php_standard.h /usr/php5/[version]/include/php/ext/standard/php_string.h /usr/php5/[version]/include/php/ext/standard/php_type.h /usr/php5/[version]/include/php/ext/standard/php_uuencode.h /usr/php5/[version]/include/php/ext/standard/php_var.h /usr/php5/[version]/include/php/ext/standard/php_versioning.h /usr/php5/[version]/include/php/ext/standard/proc_open.h /usr/php5/[version]/include/php/ext/standard/quot_print.h /usr/php5/[version]/include/php/ext/standard/reg.h /usr/php5/[version]/include/php/ext/standard/scanf.h /usr/php5/[version]/include/php/ext/standard/sha1.h /usr/php5/[version]/include/php/ext/standard/streamsfuncs.h /usr/php5/[version]/include/php/ext/standard/uniqid.h /usr/php5/[version]/include/php/ext/standard/url.h /usr/php5/[version]/include/php/ext/standard/url_scanner.h /usr/php5/[version]/include/php/ext/standard/url_scanner_ex.h /usr/php5/[version]/include/php/ext/xml/php_xml.h /usr/php5/[version]/include/php/ext/xml/expat_compat.h apc Uncommitted APC Extension bcmath Uncommitted BC Math Extension bz2 Uncommitted BZ2 Extension calendar Uncommitted Calendar Extension ctype Uncommitted Character Extension curl Uncommitted C-URL Extension dba Uncommitted Database Access Extension dom Uncommitted XML DOM Extension dtrace Uncommitted DTrace Extension exif Uncommitted EXIF Extension filter Uncommitted Filter Extension ftp Uncommitted FTP Extension gd Uncommitted GD Extension gettext Uncommitted Gettext Extension hash Uncommitted PHP Hashing Extension iconv Uncommitted GNU Iconv Compatible Extension json Uncommitted JavaScript Object Notation Extension libxml Uncommitted LibXML Extension mbstring Uncommitted Multi-byte Strings Extension openssl Uncommitted OpenSSL Extension pcntl Uncommitted Process Control Extension pcre Uncommitted PCRE Extension pdo Uncommitted PHP Database Objects Extension pdo_pgsql Uncommitted PostgreSQL PHP Database Objects Extension pgsql Uncommitted PHP PostgreSQL Native Extension posix Uncommitted PHP POSIX Emulation Extension session Uncommitted PHP Session Management Extension shmop Uncommitted PHP Shared Memory Extension simplexml Uncommitted PHP XML Extension soap Uncommitted PHP SOAP Extension sockets Uncommitted PHP Sockets Extension spl Uncommitted Standard PHP Library Extension suhosin Uncommitted Hardened PHP Security Extension sysvmsg Uncommitted SVR4 IPC Extension sysvsem Uncommitted SVR4 Semaphores Extension sysvshm Uncommitted SVR4 Shared memory Extension tcpwrap Uncommitted TCP Wrapper Library Extension tidy Uncommitted TIDY Library Extension tokenizer Uncommitted PHP Tokenizer Parser Extension xml Uncommitted LibXML Extension xlmreader Uncommitted LibXML Reader Extension xmlrpc Uncommitted LibXML RPC Extension xmlwriter Uncommitted LibXML Writer Extension xsl Uncommitted LibXSLT Extension zip Uncommitted ZIP Compression Extension zlib Uncommitted ZLib Compression Extension 7. References. [1] http://www.php.net/ [2] http://www.php.net/docs.php [3] http://www.php.net/download-docs.php [4] http://www.php.net/license/3_01.txt [5] http://bugs.php.net/ [6] http://www.libgd.org/ [7] http://curl.haxx.se/ [8] http://www.pcre.org/ [9] http://tidy.sourceforge.net/ [10] http://sourceforge.net/project/showfiles.php?group_id=12272 [11] http://www.littlecms.com/ [12] http://www.gnu.org/software/libidn/ [13] http://www.hardened-php.net/ [14] http://www.postgresql.org/ [15] http://www.apache.org/ [16] http://www.xmlsoft.org/ [17] http://www.openssl.org/ --Boundary_(ID_xe41hCusKAYzBuVOEgwXjQ)-- From unixconsole@yahoo.com Wed Mar 21 07:07:31 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LE7UUK025429 for ; Wed, 21 Mar 2007 07:07:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2LE79ru001763 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Wed, 21 Mar 2007 22:07:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900M09B8G9900@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 08:07:28 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900JHVB8FSH40@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 08:07:27 -0600 (MDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2LCYgtg009084 for ; Wed, 21 Mar 2007 14:07:27 +0000 (GMT) Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay2.sun.com with ESMTP for PSARC-EXT@Sun.COM; Wed, 21 Mar 2007 14:07:26 +0000 (Z) Received: from relay02i.sun.com (ip72.net150143-60.block3.us.syntegra.com [150.143.60.72]) by mms05es.sun.com with ESMTP id BT-MMP-1788375 for PSARC-EXT@Sun.COM; Wed, 21 Mar 2007 14:07:26 +0000 (Z) Received: from web30806.mail.mud.yahoo.com ([68.142.200.149] [68.142.200.149]) by relay0i.sun.com for PSARC-EXT@Sun.COM; Wed, 21 Mar 2007 14:07:26 +0000 (Z) Received: (qmail 10928 invoked by uid 60001); Wed, 21 Mar 2007 14:07:25 +0000 Received: from [71.2.179.191] by web30806.mail.mud.yahoo.com via HTTP; Wed, 21 Mar 2007 07:07:25 -0700 (PDT) Date: Wed, 21 Mar 2007 07:07:25 -0700 (PDT) From: Octave Orgeron Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4600AF36.8080407@Sun.COM> To: Bart Smaalders , PSARC-EXT@sun.com Cc: Stefan Teleman Message-id: <631818.10745.qm@web30806.mail.mud.yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=pVu93+0eKsLw4Zud1JPc8FyUirrL5PtIFVfCeHjXVFO8Kuxb6yQAQdXZttRTACzWaUYXtcqvrEzJivTfTT77I+kFwQDIT/20RQVIhQtSaC4Yl7Jw4RWgq84y3L68UJOCqFDYXmYdNdB2uQEazTC0qroWoki+dVkO772uNhaf0w8=; X-PMX-Version: 5.2.0.264296 X-YMail-OSG: 3i.gfWAVM1mdqc_nUTLZx2mRFOPSyKKU3vKMegoFGJhiTPze5jRnNyh0n1bLQYJ0k8ZfARi9TAetBZxxEfxhBHnNdFVJFh2Ka9HFQn0MeTXCh5TLY9t0DO.5eCzLWWvAdCPz3K2AWVE0c7XzIMYJWIUpdQlyzT_9s2vp3x_QUVb1X8TVWOPHVQJf_A-- Status: RO Content-Length: 7694 Looks good. --- Bart Smaalders wrote: > I'm sponsoring the attached fast-track for Stefan Teleman. > The requested binding is patch/micro release, and the > stability levels are as noted in the document. > > Materials are in the case directory. > > This case times out on 3/28/2007. > > - Bart > -- > Bart Smaalders Solaris Kernel Performance > barts@cyber.eng.sun.com http://blogs.sun.com/barts > > Including PHP5 with Solaris > > Stefan Teleman > 15 March 2007 > > 1. Summary and motivation > > The inclusion of PHP5 in Solaris as a component of SAPP > [Solaris, Apache, PostgreSQL, PHP] will address a current > shortcoming of SMI's software portfolio. > > The absence in Solaris of a LAMP [Linux, Apache, MySQL, PHP] > equivalent software stack has allowed Linux to create the > perception that it is the operating environment of choice for > web-based applications. > > This case seeks Micro/Patch Release Binding. > > 2. Technical issues > 2.1. Key objects. > > /usr/bin/php > /usr/bin/php-config > /usr/bin/phpize > /usr/lib/libphp5-5.2.0.so > /usr/lib/libphp5.so -> /usr/lib/libphp5-5.2.0.so > /etc/php5/php.ini > > All other objects will be contained within the /usr/php5/[version] > hierarchy. This hierarchy will loosely track that of the publicly > available version. > > The current version of PHP5 [5.2.0] is 64-bit clean and largefile > aware. A 64-bit version of PHP is being considered for a future > release. > > 2.2. Versioning > > The PHP5 development process follows the ubiquitous > "continuous development" model, typical of many Open Source > projects. > Currently, two Releases of PHP coexist, and are still under > development: PHP4 and PHP5. Also, PHP6 is currently under active > development, and is scheduled to be released sometime during 2007. > None of these three Releases make any guarantees of API and ABI > compatibility. > > The PHP versioning model has followed the .. > model. The version of PHP5 proposed for inclusion in Solaris is PHP > 5.2.0. > > 2.3. Directory Naming and Structure > > The proposed directory layout for PHP5 is: > /usr/php5/ > bin -> [version]/bin > doc -> [version]/doc > etc -> /etc/php5 > include -> [version]/include > lib -> [version]/lib > man -> [version]/man > modules -> [version]/modules > share -> [version]/share > > The detailed directory and file layout for PHP5 is provided in > Addendum 1. > > 2.4. Packaging and Delivery > > The current proposal allows for the inclusion and coexistence > of multiple versions of PHP by keeping each installation under > a version-specific subdirectory. The following package naming > convention is proposed: > > SUNWphp520root > SUNWphp520core > SUNWphp520usr > SUNWphp520man > SUNWphp520doc > > SUNWphp520root will deliver only one file, the system-wide PHP5 > configuration file: > > /etc/php5/php.ini > > SUNWphp520core will deliver the minimal filesystem objects for a > functional PHP5 Apache installation: > > SUNWphp520core: > > /usr/php5/etc -> /etc/php5 > > /usr/php5/[version]/lib > /usr/php5/[version]/modules > /usr/php5/lib -> /usr/php5/[version]/lib > /usr/php5/modules -> /usr/php5/[version]/modules > > SUNWphp520usr will deliver the additional userland and developer > filesystem objects: > > SUNWphp520usr: > > /usr/php5/[version]/bin > /usr/php5/[version]/include > /usr/php5[version]/share > /usr/php5/bin -> /usr/php5/[version]/bin > /usr/php5/include -> /usr/php5/[version]/include > /usr/php5/share -> /usr/php5[version]/share > > SUNWphp520doc will deliver the full and complete PHP5 > documentation in HTML format. > > SUNWphp520man will deliver the available man pages for PHP5: > > /usr/share/man/man1/php.1 > /usr/php5/[version]/man/man1/php.1 > /usr/php5/[version]/man/man1/php-config.1 > /usr/php5/[version]/man/man1/phpize.1 > /usr/php5/man -> /usr/php5/[version]/man > > 3. PHP5 Modules [Extensions]. > > PHP supports a loadable module interface (known in PHP parlance > as "Extensions"), allowing the PHP runtime to communicate with, > and bind to, external interfaces. This module interface also allows > for the clean integration of new PHP features or bindings. In > addition, > SMI may want to provide customers internally developed PHP > Extensions. > PHP Extensions have an associated dynamically loadable shared object > (*.so). As mentioned earlier, PHP makes no guarantee of binary > compatibility between releases. Maintaining PHP within the > constraint > of such possible binary incompatibilities motivates the directory > layout structure proposed in 2.3. > > 3.1. PHP Core Modules. > > The initial integration will provide a subset of the PHP5 > Core Extensions as delivered by the canonical PHP5 Release: > > pcre [Perl-Compatible Regular Expressions] > idn [International Domain Names Resolver] > gd [Graphics Device] > exif [EXIF Metadata Information] > psql [PostgreSQL bindings] > mbstring [Multi-Byte Strings/UTF Encoding bindings] > gettext [GNU-compatible gettext binding] > iconv [GNU compatible character encoding/conversion bindings] > xml [XML bindings] > pdo [PHP Database Objects bindings] > pgsql [PostgreSQL bindings] > soap [SOAP bindings] > spl [Standard PHP Library] > ssl [OpenSSL bindings] > tcpwrap [TCPWrap bindings] > tidy [HTML parsing and validation library] > zlib [libz compression bindings] > bz2 [libbz2 compression bindings] > zip [libzip bindings] > json [JavaScript bindings] > bcmath [Binary Calculator Math bindings] > calendar [Calendar bindings] > ctype [Character bindings] > curl [C-URL bindings] > dom [DOM XSLT bindings] > posix [POSIX bindings] > sockets [libsocket bindings] > session [PHP Session bindings] > suhosin [Hardened PHP Extension] > apc [Advanced PHP Caching Extension] > > Additional Extensions can be delivered subsequent to the initial > PHP5 integration, depending on customer requests, and on the > availability of the external dependencies required by these > Extensions. > > 4. PHP5 Internationalization. > > PHP5 provide basic I18N support via its ctype/gettext/iconv/mbstring > Extensions. As an externally developed application, PHP5 will not > provide additional Internationalization support beyond what is > provided > by the canonical distribution. > > 5. PHP5 Documentation. > > PHP5 comes with an exhaustive set of documentation available in > several > languages from the PHP Site [http://www.php.net/docs.php] [2]. > > 5.1. Full Adoption. > > The full PHP5 documentation is available for download from the PHP > Site > [http://www.php.net/download-docs.php] [3]. This documentation > collection > should be placed in the separate [doc] directory for each PHP5 > Release > [/usr/php5/[version]/doc], with an appropriate symbolic link to > /usr/php5/doc. > === message truncated ===> _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com unixconsole@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 From sommerfeld@sun.com Wed Mar 21 07:28:18 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LESI18025550 for ; Wed, 21 Mar 2007 07:28:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LESFUu013136; Wed, 21 Mar 2007 07:28:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF90050JC75M800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 07:28:17 -0700 (PDT) Received: from localhost.east.sun.com ([129.148.19.3]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900MDZC72I380@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 07:28:15 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2LERqE8007946; Wed, 21 Mar 2007 14:27:52 +0000 (GMT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l2LERqNO007945; Wed, 21 Mar 2007 10:27:52 -0400 (EDT) Date: Wed, 21 Mar 2007 10:27:51 -0400 From: Bill Sommerfeld Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4600AF36.8080407@Sun.COM> To: Bart Smaalders Cc: PSARC-EXT@sun.com, Stefan Teleman Message-id: <1174487271.7927.9.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.6.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 787 On Tue, 2007-03-20 at 21:06 -0700, Bart Smaalders wrote: > Apache 2.2 APR Libraries Uncommitted PSARC/2007/000 ... > PCRE [Perl-Compatible Regular Expressions] Uncommitted PSARC/2007/000 > IDN [Internationalized Domain Library] Uncommitted PSARC/2007/000 > GD [Graphics Device Library] Uncommitted PSARC/2007/000 > EXIF [EXIF Metadata Information] Uncommitted PSARC/2007/000 ... > CURL [C-URL Library] Uncommitted PSARC/2007/000 I'm assuming the /000 is a placeholder for cases not yet filed at the time the spec was drafted and that there are case dependencies here (2007/168 can't deliver until all six TBD dependencies are delivered) In my inbox I see cases for PCRE, CURL, IDN, LibGD, but not EXIF or APR (as distinct from Apache 2.2.4); can you clarify? - Bill From Stefan.Teleman@sun.com Wed Mar 21 08:04:08 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LF48rl026888 for ; Wed, 21 Mar 2007 08:04:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LF455i065139; Wed, 21 Mar 2007 09:04:08 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900J2DDUTI500@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 08:04:05 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900CJHDUTFIA0@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 08:04:05 -0700 (PDT) Received: from [192.9.61.55] (punchin-client-192-9-61-55.SFBay.Sun.COM [192.9.61.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2LF44Ux341710; Wed, 21 Mar 2007 08:04:04 -0700 (PDT) Date: Wed, 21 Mar 2007 11:03:09 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <1174487271.7927.9.camel@localhost> To: Bill Sommerfeld Cc: Bart Smaalders , PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <4601492D.1090700@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <1174487271.7927.9.camel@localhost> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 1255 Bill Sommerfeld wrote: > On Tue, 2007-03-20 at 21:06 -0700, Bart Smaalders wrote: > >> Apache 2.2 APR Libraries Uncommitted PSARC/2007/000 > ... >> PCRE [Perl-Compatible Regular Expressions] Uncommitted PSARC/2007/000 >> IDN [Internationalized Domain Library] Uncommitted PSARC/2007/000 >> GD [Graphics Device Library] Uncommitted PSARC/2007/000 >> EXIF [EXIF Metadata Information] Uncommitted PSARC/2007/000 > ... >> CURL [C-URL Library] Uncommitted PSARC/2007/000 > > I'm assuming the /000 is a placeholder for cases not yet filed at the > time the spec was drafted and that there are case dependencies here > (2007/168 can't deliver until all six TBD dependencies are delivered) > > In my inbox I see cases for PCRE, CURL, IDN, LibGD, but not EXIF or APR > (as distinct from Apache 2.2.4); can you clarify? At the time the Fast Tracks were written, I did not know (and could not have known) the PSARC Case Number for any of these future cases. Therefore they had placeholders. As the cases were being filed, they received Case numbers. Now that all the ARC Cases have been filed, I can update the FastTracks to reflect the corresponding ARC Case numbers. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From alan.coopersmith@Sun.COM Wed Mar 21 09:03:46 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LG3kxV029048 for ; Wed, 21 Mar 2007 09:03:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LG3i4R017228; Wed, 21 Mar 2007 09:03:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900L03GM9WY00@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 09:03:45 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900LUKGM90C00@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 09:03:45 -0700 (PDT) Received: from [192.168.0.101] (vpn-129-150-16-146.SFBay.Sun.COM [129.150.16.146]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2LG3g7Z026588; Wed, 21 Mar 2007 09:03:44 -0700 (PDT) Date: Wed, 21 Mar 2007 09:02:36 -0700 From: Alan Coopersmith Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601492D.1090700@Sun.COM> To: Stefan Teleman Cc: Bill Sommerfeld , Bart Smaalders , PSARC-EXT@Sun.COM Message-id: <4601571C.50501@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <1174487271.7927.9.camel@localhost> <4601492D.1090700@Sun.COM> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Status: RO Content-Length: 587 Stefan Teleman wrote: > At the time the Fast Tracks were written, I did not know (and could not > have known) the PSARC Case Number for any of these future cases. > Therefore they had placeholders. As the cases were being filed, they > received Case numbers. For future reference, you can have your ARC case sponsor run "sac_nextcase" to assign a case number without starting the fasttrack review, and then submit the cases for review once all the bits are filled in. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gww@eng.sun.com Wed Mar 21 13:34:19 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LKYJiZ008070 for ; Wed, 21 Mar 2007 13:34:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LKYFiS015686; Wed, 21 Mar 2007 13:34:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900A0DT56FG00@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 13:34:18 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF9008NST55UK10@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 13:34:17 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2LKYGJP001802; Wed, 21 Mar 2007 13:34:16 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2LLYEFU024878; Wed, 21 Mar 2007 13:34:15 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2LLYEmP024877; Wed, 21 Mar 2007 13:34:14 -0800 (PST) Date: Wed, 21 Mar 2007 13:34:14 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2007/168 Including PHP5 with Solaris To: bart.smaalders@sun.com, sommerfeld@sun.com Cc: PSARC-EXT@sun.com, Stefan.Teleman@sun.com Message-id: <200703212134.l2LLYEmP024877@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 513 > > Apache 2.2 APR Libraries Uncommitted PSARC/2007/000 > ... > > PCRE [Perl-Compatible Regular Expressions] Uncommitted PSARC/2007/000 > > IDN [Internationalized Domain Library] Uncommitted PSARC/2007/000 > > GD [Graphics Device Library] Uncommitted PSARC/2007/000 > > EXIF [EXIF Metadata Information] Uncommitted PSARC/2007/000 > ... > > CURL [C-URL Library] Uncommitted PSARC/2007/000 Next time, an Umbrella as to how things are intended to fit together is both desirable and appropriate. Gary.. From gww@eng.sun.com Wed Mar 21 14:05:42 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LL5f5C008796 for ; Wed, 21 Mar 2007 14:05:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LL5b0L008558 for <@sunmail1brm.central.sun.com:PSARC-EXT@Sun.COM>; Wed, 21 Mar 2007 21:05:41 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900C0TULECL00@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 15:05:38 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900BVXULD6D30@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 15:05:37 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2LL5a5V006926; Wed, 21 Mar 2007 14:05:36 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2LM5Zjf025028; Wed, 21 Mar 2007 14:05:35 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2LM5ZJK025027; Wed, 21 Mar 2007 14:05:35 -0800 (PST) Date: Wed, 21 Mar 2007 14:05:35 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2007/168 Including PHP5 with Solaris To: PSARC-EXT@sun.com, bart.smaalders@sun.com Cc: Stefan.Teleman@sun.com Message-id: <200703212205.l2LM5ZJK025027@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2024 > 2. Technical issues > 2.1. Key objects. > > /usr/lib/libphp5-5.2.0.so > /usr/lib/libphp5.so -> /usr/lib/libphp5-5.2.0.so > > All other objects will be contained within the /usr/php5/[version] > hierarchy. This hierarchy will loosely track that of the publicly > available version. > > The current version of PHP5 [5.2.0] is 64-bit clean and largefile > aware. A 64-bit version of PHP is being considered for a future > release. Why shouldn't 64 bit libraries be part of the initial putback? > > 2.2. Versioning > > The PHP5 development process follows the ubiquitous > "continuous development" model, typical of many Open Source projects. > Currently, two Releases of PHP coexist, and are still under > development: PHP4 and PHP5. Also, PHP6 is currently under active > development, and is scheduled to be released sometime during 2007. > None of these three Releases make any guarantees of API and ABI > compatibility. > > The PHP versioning model has followed the .. > model. The version of PHP5 proposed for inclusion in Solaris is PHP > 5.2.0. > > 2.3. Directory Naming and Structure > > The proposed directory layout for PHP5 is: > /usr/php5/ > bin -> [version]/bin > doc -> [version]/doc > etc -> /etc/php5 > include -> [version]/include > lib -> [version]/lib > man -> [version]/man > modules -> [version]/modules > share -> [version]/share I don't have a particular issue with this naming scheme for managing change. What I'd like to have stated is if there is a precedent that is being followed and where that precedent was established. And, if there isn't an established precedent, if this case is intended to set the precedent. How/when are obsolete instances expected to be removed. > 6.2. Imported Interfaces. > > NAME STABILITY NOTES > > Apache 2.2 APR Libraries Uncommitted PSARC/2007/000 > OpenSSL [Secure Sockets Layer] External/Volatile PSARC/2003/500 How will change be managed? Gary.. From laca@sun.com Wed Mar 21 14:24:52 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LLOpZ9009235 for ; Wed, 21 Mar 2007 14:24:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2LLOmt4020258; Thu, 22 Mar 2007 05:24:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900C01VHBTJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 14:24:47 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF90087XVHAUI50@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 14:24:47 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2LLOkIj000683; Wed, 21 Mar 2007 21:24:46 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JF900001VFJYX00@d1-emea-09.sun.com> (original mail from laca@sun.com) ; Wed, 21 Mar 2007 21:24:45 +0000 (GMT) Received: from [129.150.48.155] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JF900HIEVH710HJ@d1-emea-09.sun.com>; Wed, 21 Mar 2007 21:24:45 +0000 (GMT) Date: Wed, 21 Mar 2007 17:25:45 -0400 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <200703212134.l2LLYEmP024877@marduk.eng.sun.com> Sender: Laszlo.Peter@sun.com To: Stefan Teleman Cc: bart.smaalders@sun.com, PSARC-EXT@sun.com Reply-to: Laszlo.Peter@sun.com Message-id: <1174512345.1540.52.camel@loghost> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703212134.l2LLYEmP024877@marduk.eng.sun.com> Status: RO Content-Length: 485 > > Apache 2.2 APR Libraries Uncommitted PSARC/2007/000 > ... > > PCRE [Perl-Compatible Regular Expressions] Uncommitted PSARC/2007/000 > > IDN [Internationalized Domain Library] Uncommitted PSARC/2007/000 > > GD [Graphics Device Library] Uncommitted PSARC/2007/000 > > EXIF [EXIF Metadata Information] Uncommitted PSARC/2007/000 Just noticed this, if this is libexif, it should probably be LSARC/2004/713. Laca > ... > > CURL [C-URL Library] Uncommitted PSARC/2007/000 From jek3@sun.com Wed Mar 21 14:46:21 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LLkLLK010326 for ; Wed, 21 Mar 2007 14:46:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LLkJeK005588; Wed, 21 Mar 2007 14:46:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900D0FWH8U700@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 14:46:20 -0700 (PDT) Received: from jurassic-x4600.Eng.Sun.COM ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF9008AMWH7UK60@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Mar 2007 14:46:19 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2LLk9Ov417987; Wed, 21 Mar 2007 14:46:14 -0700 (PDT) Date: Wed, 21 Mar 2007 11:45:57 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4600AF36.8080407@Sun.COM> To: Bart Smaalders Cc: PSARC-EXT@sun.com, Stefan Teleman Message-id: <4601A795.7010600@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 820 I'm tempted to derail this, not because it is wrong, but because the versioning and change control model is far from obvious. I fear a mail discussion to resolve this will be rather painful, but lets take a shot at it first. Before I even attempt that, I'd like to know the Linux model for this. Are these components contained in any of the major distros, and if so, what updates to these components do the distros make in their updates. To clarify, if this is in RedHat (I have no idea), what would they do between RHEL4u3 and RHEL4u4 and what would they do between RHEL4 and RHEL5 (now in late Beta). Or,... do the distros just ignore this and Linux users go straight to the source? If this is the case, I think we will have a lot of difficulty forcing this version control model into Solaris. - jek3 From Stefan.Teleman@sun.com Wed Mar 21 15:00:47 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LM0l6E011147 for ; Wed, 21 Mar 2007 15:00:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LM0kQQ006986; Wed, 21 Mar 2007 15:00:47 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF90000FX5BR500@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 15:00:47 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900AJDX5AGW70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 15:00:46 -0700 (PDT) Received: from [192.9.61.55] (punchin-client-192-9-61-55.SFBay.Sun.COM [192.9.61.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2LM0juf394949; Wed, 21 Mar 2007 15:00:45 -0700 (PDT) Date: Wed, 21 Mar 2007 17:59:53 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <200703212205.l2LM5ZJK025027@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC-EXT@sun.com, bart.smaalders@sun.com Reply-to: Stefan Teleman Message-id: <4601AAD9.6010802@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703212205.l2LM5ZJK025027@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 773 Gary Winiger wrote: > Why shouldn't 64 bit libraries be part of the initial putback? Barring vehement objections, I will update the materials to include the 64-bit versions as well. >> >> NAME STABILITY NOTES >> >> Apache 2.2 APR Libraries Uncommitted PSARC/2007/000 >> OpenSSL [Secure Sockets Layer] External/Volatile PSARC/2003/500 > > How will change be managed? > > Gary.. Contracts, Contracts, Contracts. I don't know how easy it will be to upgrade OpenSSL to at least "Evolving". There's nothing more i would like than to be able to do so (since it would make my life a little easier), but OpenSSL has had a history of breaking things between release number changes. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gww@eng.sun.com Wed Mar 21 15:11:40 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LMBdCb012011 for ; Wed, 21 Mar 2007 15:11:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2LMBQMJ003944 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@Sun.COM>; Thu, 22 Mar 2007 06:11:38 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900F03XNB3V00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 15:11:35 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF9008E2XNAUI70@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 15:11:34 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2LMBYaY019923; Wed, 21 Mar 2007 15:11:34 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2LNBWDu025305; Wed, 21 Mar 2007 15:11:32 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2LNBWsO025304; Wed, 21 Mar 2007 15:11:32 -0800 (PST) Date: Wed, 21 Mar 2007 15:11:32 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2007/168 Including PHP5 with Solaris To: gww@eng.sun.com, Stefan.Teleman@sun.com Cc: PSARC-EXT@sun.com, bart.smaalders@sun.com Message-id: <200703212311.l2LNBWsO025304@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 289 > Contracts, Contracts, Contracts. > > I don't know how easy it will be to upgrade OpenSSL to at least "Evolving". I'm sure you mean Uncommitted ;-) and I'd suggest you have that conversation with the project team of 2003/500. IIRC, Volatile was the only meaningful upgrade. Gary.. From David.Comay@sun.com Wed Mar 21 15:19:21 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LMJJaY012430 for ; Wed, 21 Mar 2007 15:19:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2LMJFlC006087; Thu, 22 Mar 2007 06:19:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900201Y03OO00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 15:19:15 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900AUVY03GQ60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 15:19:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2LMJ9Q4107140; Wed, 21 Mar 2007 15:19:15 -0700 (PDT) Date: Wed, 21 Mar 2007 15:19:09 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <200703212205.l2LM5ZJK025027@marduk.eng.sun.com> Sender: comay@izimbra.SFBay.Sun.COM To: Gary Winiger Cc: PSARC-EXT@sun.com, bart.smaalders@sun.com, Stefan.Teleman@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703212205.l2LM5ZJK025027@marduk.eng.sun.com> Status: RO Content-Length: 1563 > Why shouldn't 64 bit libraries be part of the initial putback? Speaking for myself, although I believe delivering 64-bit versions of the support libraries makes sense (assuming the open source components are 64-bit clean), I don't believe delivering a 64-bit PHP is necessary at this time. I've spoken to a number of customers and developers about this and while a 64-bit PHP or Apache is certainly something desirable, it has not been expressed as a strong requirement for the moment. If someone though has data to show that this is not the case, that would definitely be of interest. Also as Stefan noted in the case, there are additional enhancements that are being looked at for the future concerning PHP and I think 64-bit could be one of them. >> The proposed directory layout for PHP5 is: >> /usr/php5/ >> bin -> [version]/bin >> doc -> [version]/doc >> etc -> /etc/php5 >> include -> [version]/include >> lib -> [version]/lib >> man -> [version]/man >> modules -> [version]/modules >> share -> [version]/share > > I don't have a particular issue with this naming scheme for > managing change. What I'd like to have stated is if there > is a precedent that is being followed and where that > precedent was established. And, if there isn't an established > precedent, if this case is intended to set the precedent. I believe the precedent that is being followed here is that of Perl (PSARC 1999/192). > How/when are obsolete instances expected to be removed. Again, I think the model here is akin to Perl. dsc From Stefan.Teleman@sun.com Wed Mar 21 15:22:35 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LMMYc8012940 for ; Wed, 21 Mar 2007 15:22:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LMMX46011502; Wed, 21 Mar 2007 15:22:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF90030JY5M0N00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 15:22:34 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900AQZY5LGL60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 15:22:33 -0700 (PDT) Received: from [192.9.61.55] (punchin-client-192-9-61-55.SFBay.Sun.COM [192.9.61.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2LMMWwc398215; Wed, 21 Mar 2007 15:22:32 -0700 (PDT) Date: Wed, 21 Mar 2007 18:21:37 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601A795.7010600@sun.com> To: Joseph Kowalski Cc: Bart Smaalders , PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <4601AFF1.5070904@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 2347 Joseph Kowalski wrote: > > I'm tempted to derail this, not because it is wrong, but because the > versioning and change control model is far from obvious. I fear a mail > discussion to resolve this will be rather painful, but lets take a shot > at it first. > > Before I even attempt that, I'd like to know the Linux model for this. > Are these components contained in any > of the major distros, and if so, what updates to these components do the > distros make in their updates. > To clarify, if this is in RedHat (I have no idea), what would they do > between RHEL4u3 and RHEL4u4 and > what would they do between RHEL4 and RHEL5 (now in late Beta). Both RedHat and SUSE (the ones i know) deliver PHP. They seem to follow the "Designer Model": every release of either RedHat or SUSE starts off by delivering a _certain_ version of PHP5. They tend to stick with it for as long as possible, and they patch it internally. This is the reason why one ends up with versions like php-5.2.0.3.1.2b (as an example), when the PHP Group has only released PHP.5.2.0. Minor upgrades (i.e. RHEL3U3 to RHEL3U4) try to maintain compatibility. Compatibility can, in fact, always be broken by shifting the blame to the original author of software. Vendor sites which use RHEL or SUSE employ a rather large number of people who keep very busy making sure that whatever puts in their box, works. This is the explanation for support contracts which advertise products such as "Our Certified Linux RHEL3". It's been certified not to explode on startup, and that's pretty much the extent of it. RHEL or SUSE customers which want different versions of PHP (or anything else) build and support their own. For Apache, SUSE delivers mpm-prefork *or* mpm-worker -- one gets to choose at installation time which one gets installed. But, they do not coexist. Same for PHP: one can choose at installation time whether one installs PHP4 or PHP5. Upgrades between Major Releases (i.e. RHEL3 to RHEL4) are no-holds-barred: there is *no expectation whatsoever* of backwards compatibility. Everything must be reinstalled, nothing is shared, and rpm's of PHP (any version) for RHEL3 will not work on RHEL4. Nobody expects them to be compatible. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gww@eng.sun.com Wed Mar 21 15:49:26 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LMnPS4014535 for ; Wed, 21 Mar 2007 15:49:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LMnPrr031881 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@Sun.COM>; Wed, 21 Mar 2007 16:49:25 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900501ZEDQJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 15:49:25 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900A4DZEDGQ80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 15:49:25 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2LMnO59025584; Wed, 21 Mar 2007 15:49:24 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2LNnNuL025386; Wed, 21 Mar 2007 15:49:23 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2LNnNRt025385; Wed, 21 Mar 2007 15:49:23 -0800 (PST) Date: Wed, 21 Mar 2007 15:49:23 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2007/168 Including PHP5 with Solaris To: gww@eng.sun.com, David.Comay@sun.com Cc: PSARC-EXT@sun.com, bart.smaalders@sun.com, Stefan.Teleman@sun.com Message-id: <200703212349.l2LNnNRt025385@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1469 > From David.Comay@Sun.COM Wed Mar 21 15:19:14 2007 > Date: Wed, 21 Mar 2007 15:19:09 -0700 (PDT) > From: David.Comay@Sun.COM > To: Gary Winiger > cc: PSARC-EXT@Sun.COM, bart.smaalders@Sun.COM, Stefan.Teleman@Sun.COM > Subject: Re: PSARC/2007/168 Including PHP5 with Solaris > > > Why shouldn't 64 bit libraries be part of the initial putback? > > Speaking for myself, although I believe delivering 64-bit versions of > the support libraries makes sense (assuming the open source components > are 64-bit clean), I don't believe delivering a 64-bit PHP is necessary > at this time. Agreed that's why I said libraries. > >> The proposed directory layout for PHP5 is: > >> /usr/php5/ > >> bin -> [version]/bin > >> doc -> [version]/doc > >> etc -> /etc/php5 > >> include -> [version]/include > >> lib -> [version]/lib I guess what's missing here is .../lib/32 -> . and .../lib/64 > >> man -> [version]/man > >> modules -> [version]/modules > >> share -> [version]/share > > > > I don't have a particular issue with this naming scheme for > > managing change. What I'd like to have stated is if there > > is a precedent that is being followed and where that > > precedent was established. And, if there isn't an established > > precedent, if this case is intended to set the precedent. > > I believe the precedent that is being followed here is that of Perl > (PSARC 1999/192). Fine. Just asking. Gary.. From jek3@sun.com Wed Mar 21 16:47:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LNlk7H019212 for ; Wed, 21 Mar 2007 16:47:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LNlUiE020934; Wed, 21 Mar 2007 23:47:44 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFA00I0123JQ500@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 17:47:43 -0600 (MDT) Received: from jurassic-x4600.Eng.Sun.COM ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFA00HEJ23JBC20@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 17:47:43 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2LNlgHB435790; Wed, 21 Mar 2007 16:47:42 -0700 (PDT) Date: Wed, 21 Mar 2007 13:47:36 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601AFF1.5070904@Sun.COM> To: Stefan Teleman Cc: Bart Smaalders , PSARC-EXT@sun.com Message-id: <4601C418.4060002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 2946 Stefan Teleman wrote: > > > Joseph Kowalski wrote: >> >> I'm tempted to derail this, not because it is wrong, but because the >> versioning and change control model is far from obvious. I fear a >> mail discussion to resolve this will be rather painful, but lets take >> a shot at it first. >> >> Before I even attempt that, I'd like to know the Linux model for >> this. Are these components contained in any >> of the major distros, and if so, what updates to these components do >> the distros make in their updates. >> To clarify, if this is in RedHat (I have no idea), what would they do >> between RHEL4u3 and RHEL4u4 and >> what would they do between RHEL4 and RHEL5 (now in late Beta). > > Both RedHat and SUSE (the ones i know) deliver PHP. > > They seem to follow the "Designer Model": every release of either > RedHat or SUSE starts off by delivering a _certain_ version of PHP5. > They tend to stick with it for as long as possible, and they patch it > internally. This is the reason why one ends up with versions like > php-5.2.0.3.1.2b (as an example), when the PHP Group has only released > PHP.5.2.0. Minor upgrades (i.e. RHEL3U3 to RHEL3U4) try to maintain > compatibility. Compatibility can, in fact, always be broken by > shifting the blame to the original author of software. > > Vendor sites which use RHEL or SUSE employ a rather large number of > people who keep very busy making sure that whatever > puts in their box, works. This is the > explanation for support contracts which advertise products such as > "Our Certified Linux RHEL3". It's been certified not to explode on > startup, and that's pretty much the extent of it. > > RHEL or SUSE customers which want different versions of PHP (or > anything else) build and support their own. > > For Apache, SUSE delivers mpm-prefork *or* mpm-worker -- one gets to > choose at installation time which one gets installed. But, they do not > coexist. Same for PHP: one can choose at installation time whether one > installs PHP4 or PHP5. > > Upgrades between Major Releases (i.e. RHEL3 to RHEL4) are > no-holds-barred: there is *no expectation whatsoever* of backwards > compatibility. Everything must be reinstalled, nothing is shared, and > rpm's of PHP (any version) for RHEL3 will not work on RHEL4. Nobody > expects them to be compatible. > > --Stefan Let me paraphrase, just to make sure I got this right. It's so much what I expected to hear, that I want to sure. At a Major release of a distro, its a no hold barred approach. They probably just grab the newest. This would be the equivalent of a Major release of Solaris, but we don't do those. In an Update release of a distro, they apply only very minor, distro specific "patches". By the proposed Uncommitted levels, this seems pretty much what we would do in a Patch/Micro release. Do I have this right? - jek3 At an update release of a distro From David.Comay@Sun.COM Wed Mar 21 16:51:26 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LNpQtB019434 for ; Wed, 21 Mar 2007 16:51:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LNpQgr026856; Wed, 21 Mar 2007 16:51:26 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFA00I0129QV200@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 17:51:26 -0600 (MDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFA00HK229PB820@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 17:51:25 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2LNpNZu107307; Wed, 21 Mar 2007 16:51:23 -0700 (PDT) Date: Wed, 21 Mar 2007 16:51:23 -0700 (PDT) From: David.Comay@Sun.COM Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <200703212349.l2LNnNRt025385@marduk.eng.sun.com> Sender: comay@izimbra.SFBay.Sun.COM To: Gary Winiger , Stefan.Teleman@Sun.COM Cc: PSARC-EXT@Sun.COM, bart.smaalders@Sun.COM, Stefan.Teleman@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703212349.l2LNnNRt025385@marduk.eng.sun.com> Status: RO Content-Length: 615 >>> Why shouldn't 64 bit libraries be part of the initial putback? >> >> Speaking for myself, although I believe delivering 64-bit versions of >> the support libraries makes sense (assuming the open source components >> are 64-bit clean), I don't believe delivering a 64-bit PHP is necessary >> at this time. > > Agreed that's why I said libraries. Ah, thanks for the clarification. Stefan, just to clarify with the respect to the PHP's own libraries - is libphp5-5.2.0.so intended for use by other consumers or is it just used by PHP itself? Namely, should the library be Uncommitted or Project Private? dsc From Stefan.Teleman@sun.com Wed Mar 21 16:59:14 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LNxDlb019999 for ; Wed, 21 Mar 2007 16:59:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LNxDaV000847; Wed, 21 Mar 2007 16:59:13 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFA00J092MP5F00@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 17:59:13 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFA00HN92MOB620@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 17:59:13 -0600 (MDT) Received: from [192.9.61.55] (punchin-client-192-9-61-55.SFBay.Sun.COM [192.9.61.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2LNxBnv413267; Wed, 21 Mar 2007 16:59:12 -0700 (PDT) Date: Wed, 21 Mar 2007 19:58:20 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601C418.4060002@sun.com> To: Joseph Kowalski Cc: Bart Smaalders , PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <4601C69C.6030506@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 1470 Joseph Kowalski wrote: > Let me paraphrase, just to make sure I got this right. It's so much > what I expected to hear, that I want to > sure. > > At a Major release of a distro, its a no hold barred approach. They > probably just grab the newest. This > would be the equivalent of a Major release of Solaris, but we don't do > those. > > In an Update release of a distro, they apply only very minor, distro > specific "patches". By the proposed > Uncommitted levels, this seems pretty much what we would do in a > Patch/Micro release. > > Do I have this right? > > - jek3 Here's a concrete example: I used to have SUSE 10.0 on one of my laptops. It had KDE 3.4.2. I then upgraded to SUSE 10.2. To me, this seems like a minor upgrade. Although YaST2 identified it as an upgrade, this was, in fact, not an upgrade, it was a full overwrite. Nothing from SUSE 10.0 was preserved, KDE was "upgraded" (overwritten) to "3.5.5 release 45.2" (which is not an official KDE release, it's KDE 3.5.5 + SUSE). Half of the KDE applications delivered with SUSE 10.0 and KDE 3.4.2 disappeared in SUSE 10.2 and KDE 3.5.5, although i requested to install the "Full KDE". I tried to install a KDE (3.4.2) rpm from SUSE 10.0. I had to use --force --nodeps to get it through. It did not work, it crashed on startup. I seems that in the Linux world, any number change is a Major Upgrade. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stefan.Teleman@sun.com Wed Mar 21 17:03:58 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2M03wQQ020117 for ; Wed, 21 Mar 2007 17:03:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2M03q5d024978; Thu, 22 Mar 2007 00:03:56 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFA00D012UJLB00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 17:03:55 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFA00AHW2UJGLB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 17:03:55 -0700 (PDT) Received: from [192.9.61.55] (punchin-client-192-9-61-55.SFBay.Sun.COM [192.9.61.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2M03s59413887; Wed, 21 Mar 2007 17:03:54 -0700 (PDT) Date: Wed, 21 Mar 2007 20:03:03 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: David.Comay@sun.com Cc: Gary Winiger , PSARC-EXT@sun.com, bart.smaalders@sun.com Reply-to: Stefan Teleman Message-id: <4601C7B7.3000700@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703212349.l2LNnNRt025385@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 1156 David.Comay@Sun.COM wrote: >>>> Why shouldn't 64 bit libraries be part of the initial putback? >>> >>> Speaking for myself, although I believe delivering 64-bit versions of >>> the support libraries makes sense (assuming the open source components >>> are 64-bit clean), I don't believe delivering a 64-bit PHP is necessary >>> at this time. >> >> Agreed that's why I said libraries. > > Ah, thanks for the clarification. > > Stefan, just to clarify with the respect to the PHP's own libraries - > is libphp5-5.2.0.so intended for use by other consumers or is it just > used by PHP itself? Namely, should the library be Uncommitted or > Project Private? > > dsc libphp5-5.2.0 plays two roles: 1. the php executable links against it 2. it is also the apache PHP module -- httpd.conf will include a directive such as LoadModule php5_module libexec/libphp5.so (without this, there is no PHP in Apache). I don't believe it can be Project Private, since it exports interfaces for Apache's consumption. I believe Uncommitted is a much more accurate classification. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From David.Comay@sun.com Wed Mar 21 17:08:50 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2M08obQ020248 for ; Wed, 21 Mar 2007 17:08:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2M08oFQ029730; Wed, 21 Mar 2007 17:08:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFA00D0332PZH00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 17:08:49 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFA00ADX32OGKC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 17:08:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2M08mMD107363; Wed, 21 Mar 2007 17:08:48 -0700 (PDT) Date: Wed, 21 Mar 2007 17:08:48 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601C7B7.3000700@Sun.COM> Sender: comay@izimbra.SFBay.Sun.COM To: Stefan Teleman Cc: Gary Winiger , PSARC-EXT@sun.com, bart.smaalders@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703212349.l2LNnNRt025385@marduk.eng.sun.com> <4601C7B7.3000700@Sun.COM> Status: RO Content-Length: 203 > I don't believe it can be Project Private, since it exports interfaces for > Apache's consumption. I believe Uncommitted is a much more accurate > classification. Thanks for the clarification. dsc From jek3@sun.com Wed Mar 21 20:59:31 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2M3xU7A023455 for ; Wed, 21 Mar 2007 20:59:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2M3xN1B016101; Thu, 22 Mar 2007 03:59:28 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFA00F03DR26200@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 20:59:26 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFA005O4DR23G40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 20:59:26 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2M3xPwY459712; Wed, 21 Mar 2007 20:59:25 -0700 (PDT) Date: Wed, 21 Mar 2007 17:59:18 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601C69C.6030506@Sun.COM> To: Stefan Teleman Cc: Bart Smaalders , PSARC-EXT@sun.com Message-id: <4601FF16.2050602@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 3076 Stefan Teleman wrote: > > > Joseph Kowalski wrote: > >> Let me paraphrase, just to make sure I got this right. It's so much >> what I expected to hear, that I want to >> sure. >> >> At a Major release of a distro, its a no hold barred approach. They >> probably just grab the newest. This >> would be the equivalent of a Major release of Solaris, but we don't >> do those. >> >> In an Update release of a distro, they apply only very minor, distro >> specific "patches". By the proposed >> Uncommitted levels, this seems pretty much what we would do in a >> Patch/Micro release. >> >> Do I have this right? >> >> - jek3 > > Here's a concrete example: > > I used to have SUSE 10.0 on one of my laptops. It had KDE 3.4.2. I > then upgraded to SUSE 10.2. To me, this seems like a minor upgrade. > Although YaST2 identified it as an upgrade, this was, in fact, not an > upgrade, it was a full overwrite. Nothing from SUSE 10.0 was > preserved, KDE was "upgraded" (overwritten) to "3.5.5 release 45.2" > (which is not an official KDE release, it's KDE 3.5.5 + SUSE). > > Half of the KDE applications delivered with SUSE 10.0 and KDE 3.4.2 > disappeared in SUSE 10.2 and KDE 3.5.5, although i requested to > install the "Full KDE". I tried to install a KDE (3.4.2) rpm from SUSE > 10.0. I had to use --force --nodeps to get it through. > > It did not work, it crashed on startup. > > I seems that in the Linux world, any number change is a Major Upgrade. > > --Stefan > Your concrete example only shows that SuSE is out of control. After using SuSE 8, 9 and 10 to test some Java installation changes, it doesn't surprise me. (I know this is open - no offense to SuSE lovers.) What I'm getting at is that the community providing this and the community consuming it (linux in general), seem to have no expectation of multiple, co-resident releases or interface stability. Going back to the earlier cases dealing with FOSS, this makes this stack either inappropriate for inclusion in Solaris or if included, only included as Volatile. The other option, would be to included it as Uncommitted, and only update it (from the community) at Minor release points. We could do point upgrades (read forks) if needed for truly serious problems, much as you asserted the distros do. This would probably be viable if we still did Minor releases at roughly the same frequency as the Linux distros, but I guess we don't do that anymore. (Insert long digression about no Minor release being scheduled here.) In any case, I don't see that keeping multiple versions of this stack on Solaris makes any sense. We could build versions into the paths, doing the moral equivalent of static linking (as seems to be proposed), but it seems this would be counter to the assertions just made about path compatibility being important when importing from the FOSS world. I don't believe having a "latest" link helps here either. If they bind against something with "latest" in the path, it gets to use a whole new set of objects when the link value changes. - jek3 From carlsonj@phorcys.east.sun.com Thu Mar 22 04:47:45 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MBliPL002000 for ; Thu, 22 Mar 2007 04:47:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MBlNVK002448; Thu, 22 Mar 2007 11:47:42 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFA00A03ZFG5R00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 04:47:40 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFA000IRZFFGPB0@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 04:47:40 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MBldcw013815; Thu, 22 Mar 2007 07:47:39 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2MBld7F013812; Thu, 22 Mar 2007 07:47:39 -0400 (EDT) Date: Thu, 22 Mar 2007 07:47:38 -0400 From: James Carlson Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601FF16.2050602@sun.com> To: Joseph Kowalski Cc: Stefan Teleman , PSARC-EXT@sun.com Message-id: <17922.27866.909391.496978@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> Status: RO Content-Length: 977 Joseph Kowalski writes: > In any case, I don't see that keeping multiple versions of this stack on > Solaris makes any sense. We could build versions into the paths, doing > the moral equivalent of static linking (as seems to be proposed), but it > seems this would be counter to the assertions just made about path > compatibility being important when importing from the FOSS world. If we have other system bits being delivered (such as subversion) that depend on out-of-date versions of the stack components, then what choice do we have? We either allow those other system bits to fail in the field, we deliver and manage to maintain multiple (accumulating) versions, or we somehow rewrite those other bits to deal with the stack's volatility. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Thu Mar 22 07:06:02 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2ME625A004681 for ; Thu, 22 Mar 2007 07:06:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2ME61oC017531; Thu, 22 Mar 2007 07:06:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB0065J5TYB300@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 08:05:58 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB0031D5TVYEC0@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 08:05:56 -0600 (MDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2ME5tVo015580; Thu, 22 Mar 2007 14:05:55 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFB009015AVWS00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 22 Mar 2007 14:05:55 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFB00C3Y5TRDT30@d1-emea-09.sun.com>; Thu, 22 Mar 2007 14:05:52 +0000 (GMT) Date: Thu, 22 Mar 2007 14:05:51 +0000 From: Darren J Moffat Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <200703212311.l2LNBWsO025304@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Stefan.Teleman@sun.com Cc: Gary Winiger , PSARC-EXT@sun.com, bart.smaalders@sun.com Message-id: <46028D3F.5080409@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703212311.l2LNBWsO025304@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 769 Gary Winiger wrote: >> Contracts, Contracts, Contracts. >> >> I don't know how easy it will be to upgrade OpenSSL to at least "Evolving". > > I'm sure you mean Uncommitted ;-) and I'd suggest you have that > conversation with the project team of 2003/500. IIRC, Volatile > was the only meaningful upgrade. and until the OpenSSL community demonstrates to the project team (for which I can speak authoritatively) that delivers OpenSSL into OpenSolaris a significant change in behaviour with respect to API and ABI stability it isn't going to be upgraded to anything other that Volatile. It was explicitly classified External because of the interface stability of the community versions not because it was "open source from outside Sun". -- Darren J Moffat From Stefan.Teleman@sun.com Thu Mar 22 07:11:21 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MEBKXg004774 for ; Thu, 22 Mar 2007 07:11:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MEBCRv016555; Thu, 22 Mar 2007 14:11:16 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB0080562SR400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 07:11:16 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB001ZV62RYW70@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 07:11:16 -0700 (PDT) Received: from [192.9.61.55] (punchin-client-192-9-61-55.SFBay.Sun.COM [192.9.61.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2MEAg95490975; Thu, 22 Mar 2007 07:10:45 -0700 (PDT) Date: Thu, 22 Mar 2007 10:09:45 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <17922.27866.909391.496978@gargle.gargle.HOWL> To: James Carlson Cc: Joseph Kowalski , PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <46028E29.5080708@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 2309 James Carlson wrote: > Joseph Kowalski writes: >> In any case, I don't see that keeping multiple versions of this stack on >> Solaris makes any sense. We could build versions into the paths, doing >> the moral equivalent of static linking (as seems to be proposed), but it >> seems this would be counter to the assertions just made about path >> compatibility being important when importing from the FOSS world. > > If we have other system bits being delivered (such as subversion) that > depend on out-of-date versions of the stack components, then what > choice do we have? > > We either allow those other system bits to fail in the field, we > deliver and manage to maintain multiple (accumulating) versions, or we > somehow rewrite those other bits to deal with the stack's volatility. This is precisely the conundrum (and i'm using this to reply to Mr. Kowalski's email as well). Introducing something like PCRE or CURL in Solaris immediately (and implicitly) creates a hard dependency between either of these, and (for example) JDS/GNOME. What happens when JDS wants to upgrade and they need a newer version of PCRE. The immediate consequence is that Apache, PHP and Subversion must go through a full regression test. This is what i meant earlier by the term "Designer Model": every Linux distro release is unique and custom tailored. Its components work together but only in that particular release. Any change, as minuscule as it may be can potentially throw the entire release off balance. As a corollary: i have not seen any of the Linux distros i am familiar with deliver multiple versions of the same "bits". There's only one version of PCRE, there's only one version of CURL, and so on. In my mind (and this is just my thinking, please take it for what it's worth), i would think that these collections of bits (SAMP, GNU, etc), would belong to a different category of "things". These are mostly userland "things", they change very quickly and often in incompatible ways. It would probably be better and more manageable. for customers if these were packaged and delivered *independently* of Solaris. At least this way customers have a way of testing before they commit to a version upgrade. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From John.Plocher@sun.com Thu Mar 22 08:08:41 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MF8exH005620 for ; Thu, 22 Mar 2007 08:08:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MF8ZD9028416; Thu, 22 Mar 2007 08:08:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00B138QFUP00@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 09:08:39 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00A868QE6R50@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 09:08:38 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2MF8cSP008534; Thu, 22 Mar 2007 07:08:38 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFB00L018NWKX00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 22 Mar 2007 08:08:38 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFB0075A8QE273A@d1-sfbay-09.sun.com>; Thu, 22 Mar 2007 08:08:38 -0700 (PDT) Date: Thu, 22 Mar 2007 08:08:33 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <17922.27866.909391.496978@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: James Carlson Cc: Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <46029BF1.4020307@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 660 James Carlson wrote: > If we have other system bits being delivered (such as subversion) that > depend on out-of-date versions of the stack components, then what > choice do we have? Or (choice #4) we treat the set of interconnected things as a consolidation, and force the consolidation to live to the expectations that it remain self- consistent. This implies that when the consolidation chooses to update Apache, the consolidation also must update subversion (etc). In a sense this is the "gentoo" model, applied to the whole consolidation; it is no longer acceptable to /just/ update a single subcomponent, the whole wad needs to be in sync. -John From Paul.Jakma@sun.com Thu Mar 22 08:17:52 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MFHp0S005961 for ; Thu, 22 Mar 2007 08:17:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2MFHkP0007322; Thu, 22 Mar 2007 23:17:48 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00C1395NKP00@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 09:17:47 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00AVZ95L6Q70@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 09:17:46 -0600 (MDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2MFHj0w027860; Thu, 22 Mar 2007 15:17:45 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFB00I018XROU00@d1-emea-09.sun.com> (original mail from Paul.Jakma@Sun.COM); Thu, 22 Mar 2007 15:17:44 +0000 (GMT) Received: from melandri.lan ([62.6.163.68]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFB00CRU95KDT30@d1-emea-09.sun.com>; Thu, 22 Mar 2007 15:17:44 +0000 (GMT) Date: Thu, 22 Mar 2007 15:17:41 +0000 (GMT) From: Paul Jakma Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46029BF1.4020307@Sun.Com> Sender: Paul.Jakma@sun.com To: John Plocher Cc: James Carlson , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> Status: RO Content-Length: 803 On Thu, 22 Mar 2007, John Plocher wrote: > In a sense this is the "gentoo" model, applied to the whole > consolidation; it is no longer acceptable to /just/ update a single > subcomponent, the whole wad needs to be in sync. Choice #5: Explicitely list the dependencies in our packages, make our tools figure out what is compatible based on dependencies. I.e. the RedHat/Debian RPM/Deb model. I believe that's what our marketing has found that our customers want. I know for a fact that the lack of such has ruled out Solaris for one highish-profile web-server deployment.. IMHO we really need to stop dealing implicitely with dependency resolution by dint of big wads... regards, -- Paul Jakma, Solaris Networking http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190 From gww@eng.sun.com Thu Mar 22 08:21:41 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MFLfo0006316 for ; Thu, 22 Mar 2007 08:21:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MFLdQX053243; Thu, 22 Mar 2007 09:21:41 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00E0F9C4Y600@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 08:21:40 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB001WA9C3YUE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 08:21:39 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MFLbqe029776; Thu, 22 Mar 2007 08:21:37 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2MGLavW026105; Thu, 22 Mar 2007 08:21:36 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2MGLalp026104; Thu, 22 Mar 2007 08:21:36 -0800 (PST) Date: Thu, 22 Mar 2007 08:21:36 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2007/168 Including PHP5 with Solaris To: John.Plocher@sun.com, Paul.Jakma@sun.com Cc: James.D.Carlson@sun.com, jek3@sun.com, PSARC-EXT@sun.com, Stefan.Teleman@sun.com Message-id: <200703221621.l2MGLalp026104@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 214 > Choice #5: Explicitely list the dependencies in our packages, make our > tools figure out what is compatible based on dependencies. I.e. the > RedHat/Debian RPM/Deb model. When will that project be reviewed? From alan.coopersmith@sun.com Thu Mar 22 09:02:57 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MG2vI5007728 for ; Thu, 22 Mar 2007 09:02:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MG2t0g012324; Thu, 22 Mar 2007 09:02:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00L01B8W3K00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 09:02:56 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00E6ZB8WBIE0@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 09:02:56 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MG2tNd015313; Thu, 22 Mar 2007 09:02:55 -0700 (PDT) Date: Thu, 22 Mar 2007 09:02:55 -0700 From: Alan Coopersmith Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46028E29.5080708@Sun.COM> To: Stefan Teleman Cc: James Carlson , Joseph Kowalski , PSARC-EXT@sun.com Message-id: <4602A8AF.7080604@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46028E29.5080708@Sun.COM> User-Agent: Thunderbird 2.0pre (X11/20070214) Status: RO Content-Length: 1007 Stefan Teleman wrote: > In my mind (and this is just my thinking, please take it for what it's > worth), i would think that these collections of bits (SAMP, GNU, etc), > would belong to a different category of "things". These are mostly > userland "things", they change very quickly and often in incompatible > ways. It would probably be better and more manageable. for customers if > these were packaged and delivered *independently* of Solaris. At least > this way customers have a way of testing before they commit to a version > upgrade. Yes - that was the recommendation LSARC made after the last PostgreSQL case, and the conclusion reached after the previous attempts to bundle things like the directory server into the OS. Putting things into the OS that you want to change incompatibly more often than the OS release cycles just causes pain for Sun and pain for customers. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gww@eng.sun.com Thu Mar 22 09:03:10 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MG391m007739 for ; Thu, 22 Mar 2007 09:03:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MG2o4E025405; Thu, 22 Mar 2007 16:03:07 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00I0TB95PF00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 09:03:05 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00G5UB92WEB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 09:03:02 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MG30eI011027; Thu, 22 Mar 2007 09:03:00 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2MH2x8g026155; Thu, 22 Mar 2007 09:02:59 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2MH2xge026154; Thu, 22 Mar 2007 09:02:59 -0800 (PST) Date: Thu, 22 Mar 2007 09:02:59 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2007/168 Including PHP5 with Solaris To: John.Plocher@sun.com, Paul.Jakma@sun.com, gww@eng.sun.com Cc: James.D.Carlson@sun.com, jek3@sun.com, PSARC-EXT@sun.com, Stefan.Teleman@sun.com Message-id: <200703221702.l2MH2xge026154@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 302 > > Choice #5: Explicitely list the dependencies in our packages, make our > > tools figure out what is compatible based on dependencies. I.e. the > > RedHat/Debian RPM/Deb model. > > When will that project be reviewed? And more to the point how will it keep Solaris out of "dll hell"? Gary.. From dduvall@zruty.sfbay.sun.com Thu Mar 22 11:48:01 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MIm0A6012391 for ; Thu, 22 Mar 2007 11:48:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MIlur1020298; Thu, 22 Mar 2007 18:47:58 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00403IVWHY00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 11:47:56 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00LSVIVWZ660@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 11:47:56 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MIlrNY023597; Thu, 22 Mar 2007 11:47:53 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MIeM0P020547; Thu, 22 Mar 2007 11:40:22 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2MIeMqo020546; Thu, 22 Mar 2007 11:40:22 -0700 (PDT) Date: Thu, 22 Mar 2007 11:40:22 -0700 From: Danek Duvall Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: Paul Jakma Cc: John Plocher , James Carlson , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <20070322184022.GK1853@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 1794 On Thu, Mar 22, 2007 at 03:17:41PM +0000, Paul Jakma wrote: > On Thu, 22 Mar 2007, John Plocher wrote: > > >In a sense this is the "gentoo" model, applied to the whole consolidation; it > >is no longer acceptable to /just/ update a single subcomponent, the whole wad > >needs to be in sync. > > Choice #5: Explicitely list the dependencies in our packages, make our tools > figure out what is compatible based on dependencies. I.e. the RedHat/Debian > RPM/Deb model. Also known as "DLL Hell". To do that right, we still need to do the testing to find out what versions of a wide variety of components are compatible with each other to make sure that we're putting the right information in. As the number of components grow, the network of possible versions increases exponentially, and we still probably have to revert to version fixing. Even if we didn't do the testing (or not much), we can still get into the situation where multiple versions of a component are required on a system because their dependents (or others up the tree) cannot use the same version, leading either to multiple versions or to some (component,version) tuples combinations simply not being installable. And multiple versions is a problem we've covered before -- you end up in situations where you get different versions of the same library in the same memory space, leading to unpredictable results. Much of the world works with that risk, and I think that we need to provide a system for people to assume that risk should they choose. But Sun's primary focus (and one I think we should be tirelessly promoting to the community) is a system configuration which is known to work. That's your supportable enterprise system, and one which is equally valid to the "anything goes, have fun" system. Danek From jek3@sun.com Thu Mar 22 12:07:04 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MJ74EF012885 for ; Thu, 22 Mar 2007 12:07:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MJ73tR028670; Thu, 22 Mar 2007 12:07:03 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00B0BJRRVN00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 12:07:03 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00BISJRQ7T00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 12:07:02 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MJ72nw582323; Thu, 22 Mar 2007 12:07:02 -0700 (PDT) Date: Thu, 22 Mar 2007 09:06:55 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <17922.27866.909391.496978@gargle.gargle.HOWL> To: James Carlson Cc: Stefan Teleman , PSARC-EXT@sun.com Message-id: <4602D3CF.8030405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 3556 James Carlson wrote: > Joseph Kowalski writes: > >> In any case, I don't see that keeping multiple versions of this stack on >> Solaris makes any sense. We could build versions into the paths, doing >> the moral equivalent of static linking (as seems to be proposed), but it >> seems this would be counter to the assertions just made about path >> compatibility being important when importing from the FOSS world. >> > > If we have other system bits being delivered (such as subversion) that > depend on out-of-date versions of the stack components, then what > choice do we have? > > We either allow those other system bits to fail in the field, we > deliver and manage to maintain multiple (accumulating) versions, or we > somehow rewrite those other bits to deal with the stack's volatility. > What do you mean by "system bits"? I'm going to assume you mean something delivered as part of the Solaris product. If this is the case, we do what the distros do and the community expects to happen: we select a set of "system bits" which are mutually consistant or we tweak those other bits to create a set of system bits that are mutually consistant. We hold steady on those bits until the commitment level allows us not to. I suggested two possible commitment levels: Uncommitted and Volatile. Both of these require us to implement contracts for "system bits" which cross consolidation boundaries. Unless the number of these are very small, Volatile would be a nightmare. It would also make this fairly useless for our customers (IMHO). Hence, we need to make it Uncommitted, and lock down on a version for the duration of a Minor release. Heh! Isn't this what the distros are asserted to do? I doubt they were happy about it either. I'd like to point out that we are proposing to do here is pretty darn close to what we as ARC members have objected to in multiple JES proposals. Let's assume that we allowed the versioned directories (and no "latest link", because that won't help and only complicates the discussion). Assume we ship 1.2.3.4-tuesday and 1.3.2.4-thursday. What do we do with the CR from a customer that requests 1.2.4.5-wednesday? Do we just ignore it, asserting the versions are just for our special selected set of applications? I'm not contending there is a good answer here. Stacks which aren't asserted to be stable are a royal pain to support. We know that. The Linux distors know that. Even the Linux consumers know that. The Linux consumers deal with this in two ways: 1) They go to the community, download latest bits and update the version delivered by their distro. If that works, they are done and happy. 2) If that doesn't work, they shove those latest bits somewhere else on the system and use this now, APPLICATION PRIVATE copy. We simply can't do better than the community will let us. We can't wave a magic wand and turn Jello into concrete. I don't want to debate this too long in e-mail. The adding of these multiple versioned directories, which require a yet unspecified inclusion/support policy, simply pushes this out of the domain of a fast-track. We will be much more efficient discussing this in a meeting (or several). If we pursue the multiple version, I'd like to be pleasantly surprised to be presented a support model which is workable and cost effective. One might be possible for a very limited number of versions (PHP4, PHP5). I'd be quite surprised if one was possible for arbitrarily deep versions. - jek3 From jek3@sun.com Thu Mar 22 12:15:02 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MJF1jj012972 for ; Thu, 22 Mar 2007 12:15:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MJEuqW028936; Thu, 22 Mar 2007 19:14:58 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB0052PK4XPV00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 12:14:57 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00LQ1K4WZ4A0@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 12:14:56 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MJEtfn583515; Thu, 22 Mar 2007 12:14:56 -0700 (PDT) Date: Thu, 22 Mar 2007 09:14:47 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46028E29.5080708@Sun.COM> To: Stefan Teleman Cc: James Carlson , PSARC-EXT@sun.com Message-id: <4602D5A7.2020904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46028E29.5080708@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 878 Stefan Teleman wrote: > In my mind (and this is just my thinking, please take it for what it's > worth), i would think that these collections of bits (SAMP, GNU, etc), > would belong to a different category of "things". These are mostly > userland "things", they change very quickly and often in incompatible > ways. It would probably be better and more manageable. for customers > if these were packaged and delivered *independently* of Solaris. At > least this way customers have a way of testing before they commit to a > version upgrade. We could call such a delivery mechanism "The Companion CD". 8^) Only partly a joke. It was created because we knew we couldn't support its contents under a Solaris support/stability model, but we are being pushed to migrate such things into the base CD, because loading the second CD is just too hard. - sigh, - jek3 From jek3@sun.com Thu Mar 22 12:28:10 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MJS9Ou013316 for ; Thu, 22 Mar 2007 12:28:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MJS6FM047903; Thu, 22 Mar 2007 13:28:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00D01KQUSF00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 12:28:06 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00BY9KQU7R10@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 12:28:06 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MJS5FT584997; Thu, 22 Mar 2007 12:28:05 -0700 (PDT) Date: Thu, 22 Mar 2007 09:27:53 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: Paul Jakma Cc: John Plocher , James Carlson , PSARC-EXT@sun.com, Stefan Teleman Message-id: <4602D8B9.1010107@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1623 Paul Jakma wrote: > On Thu, 22 Mar 2007, John Plocher wrote: > >> In a sense this is the "gentoo" model, applied to the whole >> consolidation; it is no longer acceptable to /just/ update a single >> subcomponent, the whole wad needs to be in sync. > > Choice #5: Explicitely list the dependencies in our packages, make our > tools figure out what is compatible based on dependencies. I.e. the > RedHat/Debian RPM/Deb model. We do that. Its called "pkgadd". > I believe that's what our marketing has found that our customers want. > I know for a fact that the lack of such has ruled out Solaris for one > highish-profile web-server deployment.. > > IMHO we really need to stop dealing implicitely with dependency > resolution by dint of big wads... > > regards, Once upon a time, there was a "FRU" project for Solaris. It allowed for dependencies with much finer granularity. It was killed for political reasons. Sigh,... The Solaris and RedHat/Debian RPM/Deb models have equivalent infrastructure and capabilities. The RedHat/Debian RPM/Deb model works a little better, only because their granularity is finer. If we had finer granularity in our packages, we would work just as well. Its a good idea, but an incredibly expensive proposition to implement system wide. Yea, "the dint of big wads" is a problem. But its not this problem. This problem is: A depends on B, C depends on B-prime, B and B-prime are different versions of the same package/RPM/Deb. You are just as broken on RedHat/Debian is you have two applications which require different versions which is the central issue here. - jek3 From jek3@sun.com Thu Mar 22 13:12:12 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MKCC3c014533 for ; Thu, 22 Mar 2007 13:12:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MKCAbU018868; Thu, 22 Mar 2007 13:12:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00G11MSA3K00@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 14:12:10 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB008XPMSA9R40@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 14:12:10 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MKC9im591643; Thu, 22 Mar 2007 13:12:10 -0700 (PDT) Date: Thu, 22 Mar 2007 10:12:01 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <20070322184022.GK1853@zruty.sfbay.sun.com> To: PSARC-EXT@sun.com Cc: Stefan Teleman Message-id: <4602E311.1020106@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> <20070322184022.GK1853@zruty.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1584 >> Choice #5: Explicitely list the dependencies in our packages, make our tools >> figure out what is compatible based on dependencies. I.e. the RedHat/Debian >> RPM/Deb model. >> This "choice" has lead to a discussion about the relative value of Solaris/RPM/Deb models and packaging granularity. This has been to different, overlapping distributions. Its an excellent topic to discuss, but its not this case. Not this mail thread. I mentioned a "FRU" project once killed for political reasons (its managerial association with another project which some disliked - let's leave it at that - this was a decade ago). Its interesting to note that in that decade, a new project to meet these needs has never been created. The ARC have often pushed for such a project. Sun management must believe it is not important enough to fund. (To be more accurate, there was always something else more important to fund.) Why am I rambling about this? Perhaps an OpenSolaris project could take this on. It would take a real sub-community with some very dedicated individuals. This is a hard problem if you get to start with a clean blackboard (whiteboard?). Its a very, very hard problem if you add compatibility to the mix. That said, any group that could pull this off would have instant status in the OpenSolaris community and beyond! Anyway, please don't post any more about this to this mail thread. We've seen that bad things happen when open PSARC cases go off topic (although thus far, is seems to be only Sun employees discussing). - thank you, - jek3 From unixconsole@yahoo.com Thu Mar 22 13:18:51 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MKIpuR014823 for ; Thu, 22 Mar 2007 13:18:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MKIphL012798 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 22 Mar 2007 13:18:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00I09N3ENQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 22 Mar 2007 13:18:50 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00BWWN3D7T30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 22 Mar 2007 13:18:49 -0700 (PDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2MK0JPU022132 for ; Thu, 22 Mar 2007 20:18:49 +0000 (GMT) Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay2.sun.com with ESMTP for PSARC-EXT@sun.com; Thu, 22 Mar 2007 20:18:04 +0000 (Z) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24]) by mms02es.sun.com with ESMTP id BT-MMP-300107 for PSARC-EXT@sun.com; Thu, 22 Mar 2007 20:18:04 +0000 (Z) Received: from web30811.mail.mud.yahoo.com ([68.142.201.254] [68.142.201.254]) by relay2.sun.com for PSARC-EXT@sun.com; Thu, 22 Mar 2007 20:18:03 +0000 (Z) Received: (qmail 43756 invoked by uid 60001); Thu, 22 Mar 2007 20:18:03 +0000 Received: from [71.2.179.191] by web30811.mail.mud.yahoo.com via HTTP; Thu, 22 Mar 2007 13:18:03 -0700 (PDT) Date: Thu, 22 Mar 2007 13:18:03 -0700 (PDT) From: Octave Orgeron Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4602D3CF.8030405@sun.com> To: Joseph Kowalski , James Carlson Cc: PSARC-EXT@sun.com, Stefan Teleman Message-id: <151472.43574.qm@web30811.mail.mud.yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=2uLYJwxO/obQY37mL75G0dBdNVbTWd0igKfTaGSwnc1lS2lyEHvUP5m+6A+2OOgyfuxaFbQvzMpVTx3thRlVuXPoq5NaqxS1G364DyXQ6armKWNz3kc0CVC0tXFJvzcihURxlv+1vQQso7afpFG5xGDdxl9Q+YqTlxhjChitKsU=; X-PMX-Version: 5.2.0.264296 X-YMail-OSG: G6yPtpgVM1ngwWReSyWj3uBBY7hMEtD2HnqYRo6QdwRYnA0KPn3DnOSO37Ydgg9g5w-- Status: RO Content-Length: 4903 Hi Everyone, I love the comment about jello and concrete:) I definitely agree this is a challenging issue. But at this point it's probably something that should be moved to a separate discussion so it doesn't stall things for others. We can always sort these issues out over the next couple of builds. I do like the idea of having meetings to discuss this since it's a huge topic. Hopefully, that's something we can do publicly to get the input of the community. Octave --- Joseph Kowalski wrote: > James Carlson wrote: > > Joseph Kowalski writes: > > > >> In any case, I don't see that keeping multiple versions of this > stack on > >> Solaris makes any sense. We could build versions into the paths, > doing > >> the moral equivalent of static linking (as seems to be proposed), > but it > >> seems this would be counter to the assertions just made about path > > >> compatibility being important when importing from the FOSS world. > >> > > > > If we have other system bits being delivered (such as subversion) > that > > depend on out-of-date versions of the stack components, then what > > choice do we have? > > > > We either allow those other system bits to fail in the field, we > > deliver and manage to maintain multiple (accumulating) versions, or > we > > somehow rewrite those other bits to deal with the stack's > volatility. > > > What do you mean by "system bits"? I'm going to assume you mean > something > delivered as part of the Solaris product. > > If this is the case, we do what the distros do and the community > expects > to happen: > we select a set of "system bits" which are mutually consistant or we > tweak those other > bits to create a set of system bits that are mutually consistant. We > > hold steady on > those bits until the commitment level allows us not to. > > I suggested two possible commitment levels: Uncommitted and Volatile. > > Both of > these require us to implement contracts for "system bits" which cross > > consolidation > boundaries. Unless the number of these are very small, Volatile > would > be a nightmare. > It would also make this fairly useless for our customers (IMHO). > Hence, > we need to > make it Uncommitted, and lock down on a version for the duration of a > > Minor release. > Heh! Isn't this what the distros are asserted to do? I doubt they > were > happy about it > either. > > I'd like to point out that we are proposing to do here is pretty darn > > close to what we as > ARC members have objected to in multiple JES proposals. > > Let's assume that we allowed the versioned directories (and no > "latest > link", because > that won't help and only complicates the discussion). Assume we ship > > 1.2.3.4-tuesday > and 1.3.2.4-thursday. What do we do with the CR from a customer that > > requests > 1.2.4.5-wednesday? Do we just ignore it, asserting the versions are > just > for our special > selected set of applications? > > I'm not contending there is a good answer here. Stacks which aren't > asserted to be stable > are a royal pain to support. We know that. The Linux distors know > that. > Even the Linux > consumers know that. > > The Linux consumers deal with this in two ways: > > 1) They go to the community, download latest bits and update the > > version delivered > by their distro. If that works, they are done and happy. > > 2) If that doesn't work, they shove those latest bits somewhere > else on the system and > use this now, APPLICATION PRIVATE copy. > > We simply can't do better than the community will let us. We can't > wave > a magic wand > and turn Jello into concrete. > > I don't want to debate this too long in e-mail. The adding of these > multiple versioned > directories, which require a yet unspecified inclusion/support > policy, > simply pushes > this out of the domain of a fast-track. We will be much more > efficient > discussing this > in a meeting (or several). > > If we pursue the multiple version, I'd like to be pleasantly > surprised > to be presented a > support model which is workable and cost effective. One might be > possible for a > very limited number of versions (PHP4, PHP5). I'd be quite surprised > if > one was > possible for arbitrarily deep versions. > > - jek3 > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com unixconsole@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front From jek3@sun.com Thu Mar 22 13:26:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MKQcOE014867 for ; Thu, 22 Mar 2007 13:26:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MKQXpB020832; Thu, 22 Mar 2007 20:26:35 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00J07NG8FJ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 13:26:32 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00B93NG87R50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Mar 2007 13:26:32 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MKQVVM594851; Thu, 22 Mar 2007 13:26:31 -0700 (PDT) Date: Thu, 22 Mar 2007 10:26:23 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <151472.43574.qm@web30811.mail.mud.yahoo.com> To: Octave Orgeron Cc: James Carlson , PSARC-EXT@sun.com, Stefan Teleman Message-id: <4602E66F.6030904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <151472.43574.qm@web30811.mail.mud.yahoo.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 826 Octave Orgeron wrote: > Hi Everyone, > > I love the comment about jello and concrete:) I definitely agree this > is a challenging issue. But at this point it's probably something that > should be moved to a separate discussion so it doesn't stall things for > others. We can always sort these issues out over the next couple of > builds. > Uh, OpenSolaris projects are supposed to be done when integrated. Without this being resolved, I can't see how this project can be done. (Probably also true for 2007/169, probably not true for the lower numbered proposals.) > I do like the idea of having meetings to discuss this since it's a huge > topic. Hopefully, that's something we can do publicly to get the input > of the community. > Agreed. More public than psarc-ext? What would you suggest? > Octave > - jek3 From Ed.Gould@sun.com Thu Mar 22 15:53:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MMrZsk020904 for ; Thu, 22 Mar 2007 15:53:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2MMrTRG009537; Thu, 22 Mar 2007 22:53:33 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00815U967E00@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 16:53:30 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB008DPU939HE0@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 16:53:28 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2MMrRSc024674; Thu, 22 Mar 2007 14:53:27 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFB00K01U33TW00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM); Thu, 22 Mar 2007 15:53:27 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFB0074NU922B89@d1-sfbay-09.sun.com>; Thu, 22 Mar 2007 15:53:26 -0700 (PDT) Date: Thu, 22 Mar 2007 15:53:07 -0700 From: Ed Gould Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: Sender: Ed.Gould@sun.com To: Paul Jakma Cc: John Plocher , James Carlson , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <460308D3.7000205@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_0QK/cbYGzhwbqzkOZzZ3WA)" X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1513 This is a multi-part message in MIME format. --Boundary_(ID_0QK/cbYGzhwbqzkOZzZ3WA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Paul Jakma wrote: > Choice #5: Explicitely list the dependencies in our packages, make our > tools figure out what is compatible based on dependencies. I.e. the > RedHat/Debian RPM/Deb model. The RPM tools do this horribly badly. They always list the dependencies as the selection of things present when the RPM was built. This forces the admin to upgrade things outside the realm of what they were trying to install, because the build machine was newer than the install machine. The only way to get this right is to manually list the lowest version of each dependency. It just doesn't work, for a large number of reasons. Two of them are human error (how does one manually find all the dependencies?) and test matrix explosion (I now have to test the cross product of all version combinations). -- --Ed --Boundary_(ID_0QK/cbYGzhwbqzkOZzZ3WA) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Solaris Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_0QK/cbYGzhwbqzkOZzZ3WA)-- From Paul.Jakma@sun.com Thu Mar 22 17:19:24 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2N0JNo9022802 for ; Thu, 22 Mar 2007 17:19:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2N0J9n0026162; Fri, 23 Mar 2007 08:19:20 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFB00G05Y86PQ00@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 18:19:18 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00CKBY85OS50@brm-avmta-1.central.sun.com>; Thu, 22 Mar 2007 18:19:18 -0600 (MDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2N0JGpJ001825; Fri, 23 Mar 2007 00:19:16 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFB00H01Y2ZB600@d1-emea-09.sun.com> (original mail from Paul.Jakma@Sun.COM); Fri, 23 Mar 2007 00:19:16 +0000 (GMT) Received: from melandri.lan ([62.6.163.68]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFB00CU1Y83DT50@d1-emea-09.sun.com>; Fri, 23 Mar 2007 00:19:16 +0000 (GMT) Date: Fri, 23 Mar 2007 00:19:13 +0000 (GMT) From: Paul Jakma Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460308D3.7000205@sun.com> Sender: Paul.Jakma@sun.com To: Ed Gould Cc: John Plocher , James Carlson , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Reply-to: Paul.Jakma@sun.com, Ed Gould , John Plocher , James Carlson , Joseph Kowalski , Stefan Teleman , install-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> <460308D3.7000205@sun.com> Status: RO Content-Length: 1804 NB: Reply-To set to divert this thread over to install-discuss, as per jek3's earlier email. For the broken-MUA afflicted (mutt, etc..), please honour manually ;). On Thu, 22 Mar 2007, Ed Gould wrote: > Paul Jakma wrote: > The RPM tools do this horribly badly. They always list the > dependencies as the selection of things present when the RPM was > built. This forces the admin to upgrade things outside the realm of > what they were trying to install, because the build machine was newer > than the install machine. Hmm, in what way? > The only way to get this right is to manually list the lowest version > of each dependency. It just doesn't work, for a large number of > reasons. Two of them are human error (how does one manually find all > the dependencies?) and test matrix explosion (I now have to test the > cross product of all version combinations). Hmm, but, imagine some library, library X, of which there are several updates that may be present on a machine. The soname and version symbols however remain the same. Application Y depends on it, by soname, perhaps by version symbols additionally. Why should Y (the project team say) have to look behind the curtain of the interface? If the library offers the soname+versions, then it meets the dependency. If there are problems, it's a regression in the library and should be dealt with as such (fix it and update). What's the problem exactly? That the customer has no way of knowing that library X has an update which is required to make Y work? (That potentially could be dealt with by having a 'pull up' reverse dependency, whereby the X update (X being required by Y) lists that Y regards, -- Paul Jakma, Solaris Networking http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190 From David.Comay@sun.com Fri Mar 23 01:54:25 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2N8sO2r002136 for ; Fri, 23 Mar 2007 01:54:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2N8sDe7008264; Fri, 23 Mar 2007 08:54:22 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFC00L0JM2JN700@brm-avmta-1.central.sun.com>; Fri, 23 Mar 2007 02:54:19 -0600 (MDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFC00ADDM2JVW40@brm-avmta-1.central.sun.com>; Fri, 23 Mar 2007 02:54:19 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2N8sIJZ109355; Fri, 23 Mar 2007 01:54:19 -0700 (PDT) Date: Fri, 23 Mar 2007 01:54:18 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4601FF16.2050602@sun.com> Sender: comay@izimbra.SFBay.Sun.COM To: Joseph Kowalski Cc: Stefan Teleman , PSARC-EXT@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> Status: RO Content-Length: 2674 > What I'm getting at is that the community providing this and the community > consuming it (linux in general), seem to have no expectation of multiple, > co-resident releases or interface stability. Going back to the earlier cases > dealing with FOSS, this makes this stack either inappropriate for inclusion > in Solaris or if included, only included as Volatile. I'm not sure if that's entirely true. From conversations I've had with some Linux deployments, there are both PHP4 and PHP5 software installations on some machines. Of course, only one of the stacks is likely in use at the same time but both are available. Now perhaps the two are vendor-supplied-in-/usr PHP4 and locally-compiled-in-/opt PHP5 or maybe they're both installed in some standard location. > The other option, would be to included it as Uncommitted, and only update it > (from the community) at Minor release points. We could do point upgrades > (read forks) if needed for truly serious problems, much as you asserted the > distros do. This would probably be viable if we still did Minor releases at > roughly the same frequency as the Linux distros, but I guess we don't do that > anymore. (Insert long digression about no Minor release being scheduled > here.) I understand your point about the long minor release cycles and how they might be out of sync with the frequency these open source projects rev but I'm having difficulty understanding why this issue is germane to the architecture being proposed here. The model is basically the Perl model. As you stated in the earlier paragraph, during the development of the minor release there will be a steady stream of change in say the PHP5 version integrated into OpenSolaris. At the minor release boundary, that version is at that point frozen except for upwardly-compatible change. In the next minor release, a new version of the software might be integrated and given the proposed Uncommitted binding of the interfaces, the old one might be removed. > In any case, I don't see that keeping multiple versions of this stack on > Solaris makes any sense. We could build versions into the paths, doing the > moral equivalent of static linking (as seems to be proposed), but it seems > this would be counter to the assertions just made about path compatibility > being important when importing from the FOSS world. I'm still confused regarding this assertion. It may well be that the versions that we ship are not of use to the end-user - they're either too old, too new, missing features they want, having defaults setup the "wrong" way - but I still see value in shipping multiple versions of these stacks. dsc From David.Comay@sun.com Fri Mar 23 02:17:34 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2N9HWsW002363 for ; Fri, 23 Mar 2007 02:17:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2N9HAA8001266; Fri, 23 Mar 2007 17:17:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFC00705N502V00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Mar 2007 02:17:24 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFC00DJ7N5010A0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Mar 2007 02:17:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2N9HLbN109498; Fri, 23 Mar 2007 02:17:21 -0700 (PDT) Date: Fri, 23 Mar 2007 02:17:20 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4602D3CF.8030405@sun.com> Sender: comay@izimbra.SFBay.Sun.COM To: Joseph Kowalski Cc: James Carlson , PSARC-EXT@sun.com, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> Status: RO Content-Length: 2799 > I'd like to point out that we are proposing to do here is pretty darn close > to what we as > ARC members have objected to in multiple JES proposals. Are you suggesting then that inside the bundled product, only one version of each component be shipped? One version of Apache? One version of Perl? Could you clarify perhaps some of the issue surrounding JES for those on the open PSARC list? > Let's assume that we allowed the versioned directories (and no "latest link", > because > that won't help and only complicates the discussion). Assume we ship > 1.2.3.4-tuesday > and 1.3.2.4-thursday. What do we do with the CR from a customer that > requests > 1.2.4.5-wednesday? Do we just ignore it, asserting the versions are just for > our special > selected set of applications? I assume we do the same thing that we do generally with such customer requests - we evaluate the request, weigh its severity and the opportunity is provides with all the other work we want/need to do and make a call on whether to implement it or not. We (and I mean the OpenSolaris community and not just Sun) will need to make choices on what things we should be spending our time on. And the distros (such as Sun) need to decide what to include in their distribution given what's available and their own support model. Distros, of course, can choose to not incorporate parts of OpenSolaris if they choose to (or to choose something like KDE over GNOME, PHP4 instead of PHP5, etc). > I don't want to debate this too long in e-mail. The adding of these multiple > versioned > directories, which require a yet unspecified inclusion/support policy, simply > pushes > this out of the domain of a fast-track. We will be much more efficient > discussing this > in a meeting (or several). Does that mean that you're derailing this, Joe? I'd just like to know so we can begin to gather what questions need to be answered and then schedule a full review? I'm not trying to minimize the good issues that have been brought up here. What was being proposed was the initial integration of PHP into OpenSolaris. Stefan tried to take into account (following the Perl model) with his proposal the ability to have multiple versions of the technology available on the system. How those potential versions are managed is important but for the moment, we're talking about a single version. > If we pursue the multiple version, I'd like to be pleasantly surprised to be > presented a > support model which is workable and cost effective. One might be possible > for a > very limited number of versions (PHP4, PHP5). I'd be quite surprised if one > was > possible for arbitrarily deep versions. Again using the Perl model as an example, my thinking has been that there would tend to be two versions. dsc From jek3@sun.com Fri Mar 23 12:02:29 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2NJ2SXP013456 for ; Fri, 23 Mar 2007 12:02:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2NJ2EbZ014009; Fri, 23 Mar 2007 19:02:23 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFD00A5RE7ZW800@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Mar 2007 12:02:23 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFD000WGE7ZU9C0@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Mar 2007 12:02:23 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2NJ2KrX735874; Fri, 23 Mar 2007 12:02:21 -0700 (PDT) Date: Fri, 23 Mar 2007 09:02:04 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: Paul.Jakma@sun.com, Ed Gould , John Plocher , James Carlson , Joseph Kowalski , Stefan Teleman , install-discuss@opensolaris.org Cc: PSARC-EXT@sun.com Message-id: <4604242C.9070705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> <460308D3.7000205@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 301 Paul Jakma wrote: > NB: Reply-To set to divert this thread over to install-discuss, as per > jek3's earlier email. For the broken-MUA afflicted (mutt, etc..), > please honour manually ;). My suggestion was to do what you wanted, but to get this off of PSARC*. That didn't seem to happen. - jek3 From jek3@Sun.COM Fri Mar 23 12:44:20 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2NJiIMM013883 for ; Fri, 23 Mar 2007 12:44:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2NJi9HS026316; Sat, 24 Mar 2007 03:44:13 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFD00C05G5NRE00@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Mar 2007 12:44:11 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFD000ZYG5NU5D0@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Mar 2007 12:44:11 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2NJiAmi742571; Fri, 23 Mar 2007 12:44:10 -0700 (PDT) Date: Fri, 23 Mar 2007 09:44:00 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: David.Comay@Sun.COM Cc: James Carlson , PSARC-EXT@Sun.COM, Stefan Teleman Message-id: <46042E00.9030300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 2392 I'm skipping the nested inclusion method in replying to David for the moment. I somehow think there is a disconnect which needs to be resolved first. From David's mail, I'm led to believe that only a small number of PHP versions will be on the system. Initially, only PHP5, perhaps joined by PHP4 (or 6) in the future. As I said in other mail, I suspect a workable support plan can be worked for this model. (If this works out to be the case, I would like to see a paragraph or two about it in the materials rather than "like Perl". We need to write this down sometime to avoid the "Ground Hog Day" effect.) However, if this is that case, I don't understand the benefit or use of the [version] directory level *under* PHP5: 2.3. Directory Naming and Structure The proposed directory layout for PHP5 is: /usr/php5/ bin -> [version]/bin doc -> [version]/doc .... /usr/php5/[version]/bin/php Uncommitted Executable location /usr/php5/bin/php Uncommitted Symbolic link /usr/bin/php Uncommitted Symbolic link This seems only designed to allow support for multiple, co-resident versions of PHP5. The only way I can reconcile David's statement with this structure is that Sun Solaris would only ever deliver one version of PHP5 and the [version] field's only purpose is to give a structure to allow SA's to download other versions directly from the community. The OpenSolaris reference build would also be so resticted. Other OpenSolaris distros could do what they want, but would be encouraged to do the same. What is the model here? >> I don't want to debate this too long in e-mail. The adding of these >> multiple versioned >> directories, which require a yet unspecified inclusion/support >> policy, simply pushes >> this out of the domain of a fast-track. We will be much more >> efficient discussing this >> in a meeting (or several). > > Does that mean that you're derailing this, Joe? I'd just like to know > so we can begin to gather what questions need to be answered and then > schedule a full review? Not yet. It means that if we can't make significant progress in a day or two via e-mail, *then* I will probably derail it. I'm just of the opinion that for fast-tracks with higher level issues, we try to keep them as fast-tracks for too long. Its just not efficient. We aren't quite to that point yet (IMHO). - jek3 From Stefan.Teleman@sun.com Fri Mar 23 13:25:42 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2NKPfmg014593 for ; Fri, 23 Mar 2007 13:25:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2NKPSds007530; Fri, 23 Mar 2007 20:25:38 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFD00203I2PAL00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Mar 2007 13:25:37 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFD00IR0I2P4KD0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Mar 2007 13:25:37 -0700 (PDT) Received: from [192.9.61.113] (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2NKPa7B737498; Fri, 23 Mar 2007 13:25:36 -0700 (PDT) Date: Fri, 23 Mar 2007 16:24:43 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46042E00.9030300@sun.com> To: Joseph Kowalski Cc: David.Comay@sun.com, James Carlson , PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <4604378B.20303@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 2100 Joseph Kowalski wrote: > > I'm skipping the nested inclusion method in replying to David for the > moment. I somehow think there is a disconnect which needs to be resolved > first. > > From David's mail, I'm led to believe that only a small number of PHP > versions will be on the system. Initially, only PHP5, perhaps joined by > PHP4 (or 6) in the future. As I said in other mail, I suspect a > workable support plan can be worked for this model. (If this works out > to be the case, I would like to see a paragraph or two about it in the > materials rather than "like Perl". We need to write this down sometime > to avoid the "Ground Hog Day" effect.) > > However, if this is that case, I don't understand the benefit or use of > the [version] directory level *under* PHP5: > > 2.3. Directory Naming and Structure > > The proposed directory layout for PHP5 is: > /usr/php5/ > bin -> [version]/bin > doc -> [version]/doc > > .... > > /usr/php5/[version]/bin/php Uncommitted Executable location > /usr/php5/bin/php Uncommitted Symbolic link > /usr/bin/php Uncommitted Symbolic link > > This seems only designed to allow support for multiple, co-resident > versions of PHP5. > > The only way I can reconcile David's statement with this structure is > that Sun Solaris would only ever deliver one version of PHP5 and the > [version] field's only purpose is to give a structure to allow SA's to > download other versions directly from the community. The OpenSolaris > reference build would also be so resticted. Other OpenSolaris distros > could do what they want, but would be encouraged to do the same. > > What is the model here? This is the directory structure currently in existence with Perl5: /usr/perl5/5.6.1/ /usr/perl5/5.8.4/ [ ... ] /usr/perl5/bin -> /usr/perl5/5.8.4/bin /usr/perl5/man -> /usr/perl5/5.8.4/man /usr/bin/perl -> /usr/perl5/5.8.4/bin/perl The PHP5 model is a clone. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From jek3@sun.com Fri Mar 23 15:25:12 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2NMPCsp017703 for ; Fri, 23 Mar 2007 15:25:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2NMP8wR004962; Fri, 23 Mar 2007 15:25:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFD00603NLYZM00@brm-avmta-1.central.sun.com>; Fri, 23 Mar 2007 16:25:10 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFD0018DNLXMIF0@brm-avmta-1.central.sun.com>; Fri, 23 Mar 2007 16:25:10 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2NMP8HI764831; Fri, 23 Mar 2007 15:25:09 -0700 (PDT) Date: Fri, 23 Mar 2007 12:25:00 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4604378B.20303@Sun.COM> To: Stefan Teleman Cc: David.Comay@sun.com, James Carlson , PSARC-EXT@sun.com Message-id: <460453BC.60301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <4604378B.20303@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 2414 Stefan Teleman wrote: > > > Joseph Kowalski wrote: >> >> I'm skipping the nested inclusion method in replying to David for the >> moment. I somehow think there is a disconnect which needs to be >> resolved first. >> >> From David's mail, I'm led to believe that only a small number of >> PHP versions will be on the system. Initially, only PHP5, perhaps >> joined by PHP4 (or 6) in the future. As I said in other mail, I >> suspect a workable support plan can be worked for this model. (If >> this works out to be the case, I would like to see a paragraph or two >> about it in the materials rather than "like Perl". We need to write >> this down sometime to avoid the "Ground Hog Day" effect.) >> >> However, if this is that case, I don't understand the benefit or use >> of the [version] directory level *under* PHP5: >> >> 2.3. Directory Naming and Structure >> The proposed directory layout for PHP5 is: >> /usr/php5/ >> bin -> [version]/bin >> doc -> [version]/doc >> >> .... >> >> /usr/php5/[version]/bin/php Uncommitted Executable location >> /usr/php5/bin/php Uncommitted Symbolic link >> /usr/bin/php Uncommitted Symbolic link >> >> This seems only designed to allow support for multiple, co-resident >> versions of PHP5. >> >> The only way I can reconcile David's statement with this structure is >> that Sun Solaris would only ever deliver one version of PHP5 and the >> [version] field's only purpose is to give a structure to allow SA's >> to download other versions directly from the community. The >> OpenSolaris reference build would also be so resticted. Other >> OpenSolaris distros could do what they want, but would be encouraged >> to do the same. >> >> What is the model here? > > This is the directory structure currently in existence with Perl5: > > /usr/perl5/5.6.1/ > /usr/perl5/5.8.4/ > > [ ... ] > > /usr/perl5/bin -> /usr/perl5/5.8.4/bin > /usr/perl5/man -> /usr/perl5/5.8.4/man > > /usr/bin/perl -> /usr/perl5/5.8.4/bin/perl > > The PHP5 model is a clone. > > --Stefan > I know that. In Nevada, both the 5.6.1 and 5.8.4 directories are populated. This would seem contrary to David's statements. Perhaps I should of asked "What is the Administrative and Delivery model here?". Perhaps I should also go read what we said when we OK this for Perl... 8^) - jek3 From David.Comay@sun.com Mon Mar 26 10:33:42 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QHXgNN019016 for ; Mon, 26 Mar 2007 10:33:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QHXe4b037502; Mon, 26 Mar 2007 11:33:40 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI0071BU3ZB600@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 11:33:35 -0600 (MDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI002STU3ZA6E0@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 11:33:35 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2QHXZXN111856; Mon, 26 Mar 2007 10:33:35 -0700 (PDT) Date: Mon, 26 Mar 2007 10:33:34 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46042E00.9030300@sun.com> Sender: comay@izimbra.SFBay.Sun.COM To: Joseph Kowalski Cc: James Carlson , PSARC-EXT@sun.com, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> Status: RO Content-Length: 645 > From David's mail, I'm led to believe that only a small number of PHP > versions will be on the system. Initially, only PHP5, perhaps joined by PHP4 > (or 6) in the future. As I said in other mail, I suspect a workable support > plan can be worked for this model. (If this works out to be the case, I would > like to see a paragraph or two about it in the materials rather than "like > Perl". We need to write this down sometime to avoid the "Ground Hog Day" > effect.) Yes, I think there will be a small number of PHP versions. But I don't mean to imply that for a particular major version of PHP that there will only be one. dsc From John.Plocher@sun.com Mon Mar 26 10:46:40 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QHkd4l019225 for ; Mon, 26 Mar 2007 10:46:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QHkPg9004273; Tue, 27 Mar 2007 01:46:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI00C01UPO6H00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 10:46:36 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI0097RUPN1CA0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 10:46:35 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QHkZVd012023; Mon, 26 Mar 2007 09:46:35 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFI00A01U23KJ00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 26 Mar 2007 10:46:35 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFI0071XUPG2BRB@d1-sfbay-09.sun.com>; Mon, 26 Mar 2007 10:46:28 -0700 (PDT) Date: Mon, 26 Mar 2007 10:46:25 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: Sender: John.Plocher@sun.com To: David.Comay@sun.com Cc: Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <460806F1.6050805@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 1546 I would like to suggest that the design pattern being hashed out here (i.e., how to have multiple versions of a component installed on a given system) be explicitly called out and approved as part of this set of cases as an ARC best practice. 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. -John David.Comay@Sun.COM wrote: >> From David's mail, I'm led to believe that only a small number of PHP >> versions will be on the system. Initially, only PHP5, perhaps joined >> by PHP4 (or 6) in the future. As I said in other mail, I suspect a >> workable support plan can be worked for this model. (If this works out >> to be the case, I would like to see a paragraph or two about it in the >> materials rather than "like Perl". We need to write this down >> sometime to avoid the "Ground Hog Day" effect.) > > Yes, I think there will be a small number of PHP versions. But I don't > mean to imply that for a particular major version of PHP that there > will only be one. > > dsc > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Stefan.Teleman@sun.com Mon Mar 26 10:58:53 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QHwrcx019870 for ; Mon, 26 Mar 2007 10:58:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QHwqtc029006; Mon, 26 Mar 2007 10:58:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI00909VA5RE00@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 11:58:53 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI004CTVA4CB80@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 11:58:52 -0600 (MDT) Received: from [192.9.61.113] (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2QHwp9t170487; Mon, 26 Mar 2007 10:58:51 -0700 (PDT) Date: Mon, 26 Mar 2007 12:57:57 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460806F1.6050805@Sun.Com> To: John Plocher Cc: David.Comay@sun.com, Joseph Kowalski , PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <4607FB95.4010005@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 1983 From my experience, and from many others' experience with the PHP Group: The PHP Group currently has *no interest whatsoever* in Solaris. This may change in the future, but not within a predictable timeframe. Tying the approval of this ARC Case to the acceptance upstream (at the PHP Group) of our build configurations and directory structures, is functionally equivalent to derailing this case indefinitely. --Stefan ---- John Plocher wrote: > I would like to suggest that the design pattern being hashed out here > (i.e., how to have multiple versions of a component installed on > a given system) be explicitly called out and approved as part of this > set of cases as an ARC best practice. > > 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. > > -John > > > David.Comay@Sun.COM wrote: >>> From David's mail, I'm led to believe that only a small number of PHP >>> versions will be on the system. Initially, only PHP5, perhaps joined >>> by PHP4 (or 6) in the future. As I said in other mail, I suspect a >>> workable support plan can be worked for this model. (If this works >>> out to be the case, I would like to see a paragraph or two about it >>> in the materials rather than "like Perl". We need to write this down >>> sometime to avoid the "Ground Hog Day" effect.) >> >> Yes, I think there will be a small number of PHP versions. But I don't >> mean to imply that for a particular major version of PHP that there >> will only be one. -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stefan.Teleman@sun.com Mon Mar 26 11:04:20 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QI4JcR020051 for ; Mon, 26 Mar 2007 11:04:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QI4Dn7011671; Tue, 27 Mar 2007 02:04:15 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI00A09VJ2GY00@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 12:04:14 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.68.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI004D7VJ1CB90@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 12:04:13 -0600 (MDT) Received: from [192.9.61.113] (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2QI4CDY171151; Mon, 26 Mar 2007 11:04:12 -0700 (PDT) Date: Mon, 26 Mar 2007 13:03:15 -0400 From: Stefan Teleman Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460806F1.6050805@Sun.Com> To: John Plocher Cc: David.Comay@sun.com, Joseph Kowalski , PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <4607FCD3.5060909@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> User-Agent: Thunderbird 1.5.0.7 (X11/20060915) Status: RO Content-Length: 2098 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. I would caution that tying the approval of this ARC Case to the acceptance upstream (by the PHP Group) of our build configuration tweaks and directory structure changes, is functionally equivalent to derailing this ARC Case indefinitely. --Stefan ------ John Plocher wrote: > I would like to suggest that the design pattern being hashed out here > (i.e., how to have multiple versions of a component installed on > a given system) be explicitly called out and approved as part of this > set of cases as an ARC best practice. > > 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. > > -John > > > David.Comay@Sun.COM wrote: >>> From David's mail, I'm led to believe that only a small number of PHP >>> versions will be on the system. Initially, only PHP5, perhaps joined >>> by PHP4 (or 6) in the future. As I said in other mail, I suspect a >>> workable support plan can be worked for this model. (If this works >>> out to be the case, I would like to see a paragraph or two about it >>> in the materials rather than "like Perl". We need to write this down >>> sometime to avoid the "Ground Hog Day" effect.) >> >> Yes, I think there will be a small number of PHP versions. But I don't >> mean to imply that for a particular major version of PHP that there >> will only be one. >> >> dsc >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org > -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From David.Comay@sun.com Mon Mar 26 11:05:51 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QI5n0H020214 for ; Mon, 26 Mar 2007 11:05:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QI5iMF012296; Tue, 27 Mar 2007 02:05:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI00D0HVLJ6I00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 11:05:43 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI009NIVLJ1AD0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 11:05:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2QI5hSp111947; Mon, 26 Mar 2007 11:05:43 -0700 (PDT) Date: Mon, 26 Mar 2007 11:05:43 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460806F1.6050805@Sun.Com> Sender: comay@izimbra.SFBay.Sun.COM To: John Plocher Cc: Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> Status: RO Content-Length: 1499 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/ 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 From Nicolas.Williams@sun.com Mon Mar 26 11:20:12 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QIKCdb020658 for ; Mon, 26 Mar 2007 11:20:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QIK9wh051226; Mon, 26 Mar 2007 12:20:11 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI00D01W9MSH00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 11:20:10 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI009R1W9L1FD0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 11:20:10 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2QIJN4E029188; Mon, 26 Mar 2007 13:19:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2QIJNqj029187; Mon, 26 Mar 2007 13:19:23 -0500 (CDT) Date: Mon, 26 Mar 2007 13:19:23 -0500 From: Nicolas Williams Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: David.Comay@sun.com Cc: John Plocher , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <20070326181920.GM25751@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1168 On Mon, Mar 26, 2007 at 11:05:43AM -0700, David.Comay@Sun.COM wrote: > 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/ > 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). Do we preserve /usr/bin/ link replacement on upgrade? Personally I think that customers should not replace /usr/bin/ links, nor should we support it. The versioning issue exists with or without OpenSolaris, so customers generally have to [or are better off if they] reference specific versions of Perl/python/whatever from their applications rather than generic "latest version" links. "Latest version" links are useful for users and developers early on during development, and for generic scripts that use #! but aren't "built" and therefore have to use /bin/ in order to have a chance of running at all. We'll probably be better off telling customers as much too. Nico -- From carlsonj@phorcys.east.sun.com Mon Mar 26 11:57:53 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QIvqLa021358 for ; Mon, 26 Mar 2007 11:57:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QIvllo012311; Mon, 26 Mar 2007 19:57:49 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI00F0VY0ABX00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 11:57:46 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI00DMOY09XY20@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 11:57:46 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2QIvjnV026152; Mon, 26 Mar 2007 14:57:45 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2QIvjNV026149; Mon, 26 Mar 2007 14:57:45 -0400 (EDT) Date: Mon, 26 Mar 2007 14:57:45 -0400 From: James Carlson Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4607FCD3.5060909@Sun.COM> To: Stefan Teleman Cc: John Plocher , Joseph Kowalski , PSARC-EXT@sun.com Message-id: <17928.6057.283590.38555@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <4607FCD3.5060909@Sun.COM> Status: RO Content-Length: 1908 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. I somewhat agree with John about the design pattern issue, and I agree with his "would like to see" comments about pushing the changes back upstream -- I think the same thing is true in many other projects -- but I can't see gating integration on any such thing. The project team is the one that has to sign up to maintain any local deltas. I think it's fine advice to say "try to minimize by pushing upstream," but not something that ought to be a requirement as it slaves Solaris architecture to third-party politics. > I would caution that tying the approval of this ARC Case to the acceptance > upstream (by the PHP Group) of our build configuration tweaks and directory > structure changes, is functionally equivalent to derailing this ARC Case > indefinitely. A process note for others listening in on the discussion: the above text implies something other than what "derail" means in this context. "Derail" actually means "this isn't a fast-track; it requires a full review." It's not a pejorative term, and there's no way to apply a time span to it ("indefinitely"). Cases that either require extensive discussion (this one might be that way) or that require a written ARC opinion (John's design pattern request would need that) cannot be handled as fast-tracks. They're derailed so that the meeting can happen (if needed) and the opinion written (always required). The right term would be "deny," but I don't think this case is near that. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From John.Plocher@sun.com Mon Mar 26 11:58:59 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QIwwMl021370 for ; Mon, 26 Mar 2007 11:58:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QIwobA004172; Tue, 27 Mar 2007 02:58:55 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFI00F03Y244K00@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 12:58:52 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFI0042WY23CAF0@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 12:58:52 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QIwpFx009762; Mon, 26 Mar 2007 10:58:51 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFI00I01XY5TK00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 26 Mar 2007 11:58:51 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFI007MJY222B3C@d1-sfbay-09.sun.com>; Mon, 26 Mar 2007 11:58:51 -0700 (PDT) Date: Mon, 26 Mar 2007 11:58:47 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: Sender: John.Plocher@sun.com To: David.Comay@sun.com Cc: Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <460817E7.5010300@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 2189 Stefan Teleman wrote: > The PHP Group currently has *no interest whatsoever* in Solaris. That is too bad, but doesn't really change my suggestion that it would be good to push these changes upstream so that others could benefit from it. Ask yourself how the various OpenSolaris distros (including pseudo-distros like SunFreeware, Blastwave, ...) could all benefit from this work? Could we get to the point in the future that, no matter where you choose to get your components from, they all install into a predictable place? You are right in one aspect - as a /suggestion/, this is NOT intended to be a predicate for approval of this case. In formal ARC-eese, I would like to see: TCR - articulate this design pattern ("just like Perl...") into a formal BestPractice that can be published on the ARC Community pages (I will happily help with the logistics of making this part happen), and Advice: Push back these changes so that upstream component owners affected by this design pattern (not /just/ PHP) can take advantage of this best practice. -John David.Comay@Sun.COM wrote: > 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. 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?. -John From jek3@sun.com Mon Mar 26 12:54:24 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QJsNxq022723 for ; Mon, 26 Mar 2007 12:54:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QJsM1j012819; Mon, 26 Mar 2007 13:54:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ009110MMMM00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 12:54:22 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ004K00MLG430@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 12:54:21 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2QJsHO0231667; Mon, 26 Mar 2007 12:54:19 -0700 (PDT) Date: Mon, 26 Mar 2007 09:54:03 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460806F1.6050805@Sun.Com> To: John Plocher Cc: David.Comay@sun.com, PSARC-EXT@sun.com, Stefan Teleman Message-id: <460824DB.7030500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1738 John Plocher wrote: > I would like to suggest that the design pattern being hashed out here > (i.e., how to have multiple versions of a component installed on > a given system) be explicitly called out and approved as part of this > set of cases as an ARC best practice. There already is a best practice for this. If I'd ever written the opinion for 2003/321 Multiple JRE support, you'd find it there. I should probably do that. The important points are: 1) This was an exception, allowed because Sun encouraged the bundling of JRE's with third-party products. 2) A lot of infrastructure was required. So, we currently have a best practice, and the best practice is "don't". Times change, and best practices can change, but I don't think they should change by a fast-track (or any type of case) which provides a mechanism without policy. Just like the original cases about "Getting with the Freeware Program" took a lot of effort, this will probably also take significant effort (but hopefully not as much as those circa 2000 cases did). Thus far, the best guess I have at a policy is, "few, but at any level". In this case, since the project team has strongly asserted that the PHP community has no interest in Solaris (which is OK) and a dubious interest in interface stability (which isn't OK), we have two viable choices: Deny the component. Implement a model very close to that used by the major UNIX distros. This appears to be to lock in on one for the duration of what we would call a Minor release. There are many variants on how an SA could get a newer version, but the point is they have to actively "get it" and it would probably be marginally supported. - jek3 From jek3@sun.com Mon Mar 26 13:06:10 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QK69w5023111 for ; Mon, 26 Mar 2007 13:06:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QK61Lm004280; Tue, 27 Mar 2007 04:06:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ00I0N162CN00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 13:06:02 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00DLS162XU70@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 13:06:02 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2QK5xip234435; Mon, 26 Mar 2007 13:06:00 -0700 (PDT) Date: Mon, 26 Mar 2007 10:05:45 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460817E7.5010300@Sun.Com> To: John Plocher Cc: David.Comay@sun.com, PSARC-EXT@sun.com, Stefan Teleman Message-id: <46082799.6020500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 705 John Plocher wrote: > You are right in one aspect - as a /suggestion/, this is NOT intended > to be a predicate for approval of this case. In formal ARC-eese, I would > like to see: > > TCR - articulate this design pattern ("just like Perl...") > into a formal BestPractice that can be published on the > ARC Community pages (I will happily help with the logistics > of making this part happen), and Can't TCR that. A TCR must be written to be explicit such that no further review is required. I think I'd like to review the "design pattern". Its got to be part of the materials before this can be approved (or another case, upon which this is dependent). - jek3 From John.Plocher@Sun.COM Mon Mar 26 13:25:09 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QKP8h7023942 for ; Mon, 26 Mar 2007 13:25:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QKOwi3020045; Mon, 26 Mar 2007 21:25:06 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ00C0321TN900@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 13:25:05 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ004PR21SG440@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 13:25:04 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QKP3qw020275; Mon, 26 Mar 2007 12:25:03 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFJ009011YP1H00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 26 Mar 2007 13:25:03 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFJ0075521Q2BHC@d1-sfbay-09.sun.com>; Mon, 26 Mar 2007 13:25:02 -0700 (PDT) Date: Mon, 26 Mar 2007 13:24:59 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46082799.6020500@sun.com> Sender: John.Plocher@Sun.COM To: Joseph Kowalski Cc: David.Comay@Sun.COM, PSARC-EXT@Sun.COM, Stefan Teleman Message-id: <46082C1B.70707@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 1399 Joseph Kowalski wrote: > John Plocher wrote: >> You are right in one aspect - as a /suggestion/, this is NOT intended >> to be a predicate for approval of this case. In formal ARC-eese, I would >> like to see: >> >> TCR - articulate this design pattern ("just like Perl...") >> into a formal BestPractice that can be published on the >> ARC Community pages (I will happily help with the logistics >> of making this part happen), and > Can't TCR that. A TCR must be written to be explicit such that no further > review is required. I think I'd like to review the "design pattern". > Its got to > be part of the materials before this can be approved (or another case, upon > which this is dependent). > > - jek3 > We seem to have several precedents - Perl, Java, XPGn, versioned DSOs, Multi-Installation and Management of Layered Products for Java ES, etc that should be brought into some sort of alignment here. I'm reluctantly OK with making this a NEED SPEC; I was hoping to decouple it from the approval cycle for the project, though. That is, I'd like to say something like This project is approved now, and one of its deliverables is the BestPractice that codifies the multi-version install design pattern that it used. rather than This project needs to construct the Best Practice before it can get ARC approval. -John From fielding@gbiv.com Mon Mar 26 13:31:44 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QKVihT024102 for ; Mon, 26 Mar 2007 13:31:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QKVei4004777; Mon, 26 Mar 2007 13:31:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ000052CUH400@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 14:31:42 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00FB02CTPU50@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 14:31:41 -0600 (MDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QKUcGL013973; Mon, 26 Mar 2007 20:31:41 +0000 (GMT) Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay2.sun.com with ESMTP; Mon, 26 Mar 2007 20:31:40 +0000 (Z) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54]) by mms02es.sun.com with ESMTP id BT-MMP-2457447; Mon, 26 Mar 2007 20:31:40 +0000 (Z) Received: from spaceymail-a1.g.dreamhost.com ([208.97.132.74] [208.97.132.74]) by relay3.sun.com with ESMTP; Mon, 26 Mar 2007 20:31:40 +0000 (Z) Received: from [192.168.0.133] (ip72-211-200-45.oc.oc.cox.net [72.211.200.45]) by spaceymail-a1.g.dreamhost.com (Postfix) with ESMTP id 5E11881616; Mon, 26 Mar 2007 13:31:37 -0700 (PDT) Date: Mon, 26 Mar 2007 13:32:07 -0700 From: "Roy T. Fielding" Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <17928.6057.283590.38555@gargle.gargle.HOWL> To: James Carlson Cc: Stefan Teleman , John Plocher , Joseph Kowalski , PSARC-EXT@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <4607FCD3.5060909@Sun.COM> <17928.6057.283590.38555@gargle.gargle.HOWL> Status: RO Content-Length: 2642 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 From jek3@sun.com Mon Mar 26 14:19:18 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QLJIgJ026497 for ; Mon, 26 Mar 2007 14:19:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QLJHMJ016543; Mon, 26 Mar 2007 14:19:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ00L054K5SO00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 14:19:17 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00DPY4K4XR80@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 14:19:17 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2QLJG4x248901; Mon, 26 Mar 2007 14:19:16 -0700 (PDT) Date: Mon, 26 Mar 2007 11:19:02 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46082C1B.70707@Sun.Com> To: John Plocher Cc: David.Comay@sun.com, PSARC-EXT@sun.com, Stefan Teleman Message-id: <460838C6.4000604@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1830 John Plocher wrote: > Joseph Kowalski wrote: >> John Plocher wrote: >>> You are right in one aspect - as a /suggestion/, this is NOT intended >>> to be a predicate for approval of this case. In formal ARC-eese, I >>> would >>> like to see: >>> >>> TCR - articulate this design pattern ("just like Perl...") >>> into a formal BestPractice that can be published on the >>> ARC Community pages (I will happily help with the logistics >>> of making this part happen), and >> Can't TCR that. A TCR must be written to be explicit such that no >> further >> review is required. I think I'd like to review the "design >> pattern". Its got to >> be part of the materials before this can be approved (or another >> case, upon >> which this is dependent). >> >> - jek3 >> > > We seem to have several precedents - Perl, Java, XPGn, versioned DSOs, > Multi-Installation and Management of Layered Products for Java ES, etc > that should be brought into some sort of alignment here. > > I'm reluctantly OK with making this a NEED SPEC; I was hoping to decouple > it from the approval cycle for the project, though. That is, I'd like to > say something like > > This project is approved now, and one of its deliverables is the > BestPractice that codifies the multi-version install design pattern > that it used. > > rather than > > This project needs to construct the Best Practice before it can get > ARC approval. > > -John I'm not willing to allow a project to integrate with a structure which assumes one delivery model which may not be in-line with the Best Practice they are asked to deliver. Either as a TCR, or as a requirement of the case, they don't integrate until it happens, so I fail to see what is gained. As Advisory, there is no guarentee it ever happens. - jek3 From Nicolas.Williams@sun.com Mon Mar 26 14:35:24 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QLZNO8026752 for ; Mon, 26 Mar 2007 14:35:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QLYtiM036675; Mon, 26 Mar 2007 15:34:56 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ00J0N5A7IH00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 14:34:55 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ004JZ5A7G980@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 14:34:55 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2QLY9e5029560; Mon, 26 Mar 2007 16:34:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2QLY9qn029559; Mon, 26 Mar 2007 16:34:09 -0500 (CDT) Date: Mon, 26 Mar 2007 16:34:08 -0500 From: Nicolas Williams Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <20070322184022.GK1853@zruty.sfbay.sun.com> To: Danek Duvall Cc: Paul Jakma , John Plocher , James Carlson , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <20070326213406.GW25751@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> <20070322184022.GK1853@zruty.sfbay.sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 735 On Thu, Mar 22, 2007 at 11:40:22AM -0700, Danek Duvall wrote: > On Thu, Mar 22, 2007 at 03:17:41PM +0000, Paul Jakma wrote: > > Choice #5: Explicitely list the dependencies in our packages, make our tools > > figure out what is compatible based on dependencies. I.e. the RedHat/Debian > > RPM/Deb model. > > Also known as "DLL Hell". Particularly when multiple versions of a library can end up being loaded in one process. Though libraries other than libc or interposers can generally be designed so that they are loaded as local groups and multiple versions can exist the same process. We should encourage such library design. Of course, that's specific to C; libraries/modules for other languages are another story. Nico -- From John.Plocher@sun.com Mon Mar 26 14:39:49 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QLdm5h026771 for ; Mon, 26 Mar 2007 14:39:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QLdf4R018363; Mon, 26 Mar 2007 22:39:46 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ006095I7Z800@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 15:39:43 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00FUU5I7PO80@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 15:39:43 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QLdgKY012602; Mon, 26 Mar 2007 13:39:42 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFJ00701573LY00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 26 Mar 2007 14:39:42 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFJ007W55I626C9@d1-sfbay-09.sun.com>; Mon, 26 Mar 2007 14:39:42 -0700 (PDT) Date: Mon, 26 Mar 2007 14:39:39 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <20070326213406.GW25751@Sun.COM> Sender: John.Plocher@sun.com To: Nicolas Williams Cc: Danek Duvall , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman , James Carlson , Paul Jakma Message-id: <46083D9B.1020109@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> <20070322184022.GK1853@zruty.sfbay.sun.com> <20070326213406.GW25751@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 235 Nicolas Williams wrote: > Though libraries other than libc or interposers can > generally be designed so that they are loaded as local groups and > multiple versions can exist the same process. Can you say more about this? -John From Nicolas.Williams@Sun.COM Mon Mar 26 14:51:17 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QLpGk8027015 for ; Mon, 26 Mar 2007 14:51:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QLpDwD001666; Mon, 26 Mar 2007 14:51:13 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ0080561C8O00@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 15:51:12 -0600 (MDT) Received: from binky.central.sun.com ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00FNL61BQ080@brm-avmta-1.central.sun.com>; Mon, 26 Mar 2007 15:51:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2QLoPim029591; Mon, 26 Mar 2007 16:50:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2QLoPH0029590; Mon, 26 Mar 2007 16:50:25 -0500 (CDT) Date: Mon, 26 Mar 2007 16:50:25 -0500 From: Nicolas Williams Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46083D9B.1020109@Sun.Com> To: John Plocher Cc: Danek Duvall , Joseph Kowalski , PSARC-EXT@Sun.COM, Stefan Teleman , James Carlson , Paul Jakma Message-id: <20070326215018.GX25751@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> <20070322184022.GK1853@zruty.sfbay.sun.com> <20070326213406.GW25751@Sun.COM> <46083D9B.1020109@Sun.Com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1110 On Mon, Mar 26, 2007 at 02:39:39PM -0700, John Plocher wrote: > Nicolas Williams wrote: > >Though libraries other than libc or interposers can > >generally be designed so that they are loaded as local groups and > >multiple versions can exist the same process. > > Can you say more about this? Yes. Though you really should ask Rod Evans and the linker team rather than take my word for this. Using ld's -B local and -B group options, or using dlopen(3C) with the RTLD_LOCAL and RTLD_GROUP flags it should be possible to have multiple versions of a library loaded inside a single process, provided that the library doesn't have global process state beyond global variables (e.g., tmp files named after PIDs), and provided that all callers of the library declare it as a local group dependency or load it as a local group. dlopen(3C) doesn't have a version argument though, so the soname has to have the version in it. In practice it's not realistic to expect that all libraries are designed so this works and all callers call them in this way. But perhaps it's not unrealistic going forward? Nico -- From John.Plocher@sun.com Mon Mar 26 14:57:30 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QLvTHU027532 for ; Mon, 26 Mar 2007 14:57:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QLvOr9015300; Tue, 27 Mar 2007 05:57:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ000036BPDH00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 14:57:25 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00DJZ6BOXUC0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 14:57:24 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QLvOYs002607; Mon, 26 Mar 2007 13:57:24 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFJ003016B8VR00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 26 Mar 2007 14:57:24 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFJ007XM6BM27MZ@d1-sfbay-09.sun.com>; Mon, 26 Mar 2007 14:57:22 -0700 (PDT) Date: Mon, 26 Mar 2007 14:57:19 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460838C6.4000604@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: David.Comay@sun.com, PSARC-EXT@sun.com, Stefan Teleman Message-id: <460841BF.6050105@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> <460838C6.4000604@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 1333 Joseph Kowalski wrote: > Either as a TCR, or as a requirement of the case, they don't integrate > until it happens, so I fail to see what is gained. It lets the ARC review reach closure quicker, which is good for all concerned. > I'm not willing to allow a project to integrate with a structure which > assumes one delivery model which may not be in-line with the Best > Practice they are asked to deliver. Neither am I - go back and reread what I wrote, including the part where I said "codifies the ... design pattern that it used". I presume that the rest of this review will sort out the specific requirements for that design-pattern, which then (by definition) will be in-line with what they need to write about. Based on this conversation, I predict that the design pattern will be either 1) Do it "Just like Perl" and "Just like Java", or 2) Don't do it like Perl of Java, instead do it instead. For the life of me, I don't know why you are pushing "door number 2", but that seems to be your target... > As Advisory, there is no guarantee it ever happens. Again, my wording was "TCR - articulate this design pattern", which is not an Advisory at all. The only decoupling I was looking for was the wordsmithing of the BP itself, not the determination of the proper design pattern. -John From John.Plocher@sun.com Mon Mar 26 15:04:32 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QM4WoX027692 for ; Mon, 26 Mar 2007 15:04:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QM4UbX043111; Mon, 26 Mar 2007 16:04:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ000096NITE00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 15:04:30 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00DTW6NHXRA0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 15:04:29 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QM4TUn003549; Mon, 26 Mar 2007 14:04:29 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFJ00D016LEBV00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 26 Mar 2007 15:04:29 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFJ0072F6N82BTC@d1-sfbay-09.sun.com>; Mon, 26 Mar 2007 15:04:20 -0700 (PDT) Date: Mon, 26 Mar 2007 15:04:17 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <20070326215018.GX25751@Sun.COM> Sender: John.Plocher@sun.com To: Nicolas Williams Cc: Danek Duvall , James Carlson , PSARC-EXT@sun.com, Stefan Teleman , Joseph Kowalski , Paul Jakma Message-id: <46084361.8010203@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <46029BF1.4020307@Sun.Com> <20070322184022.GK1853@zruty.sfbay.sun.com> <20070326213406.GW25751@Sun.COM> <46083D9B.1020109@Sun.Com> <20070326215018.GX25751@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 422 Nicolas Williams wrote: > provided that all callers of the > library declare it as a local group dependency or load it as a local > group. This seems unlikely to happen for the majority of others, but maybe we could do this for all the things we do ourselves - make sure that our stuff continues to work in the face of future library mixing and document how we did it so others could choose to improve as well. -John From jek3@sun.com Mon Mar 26 15:15:48 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QMFlX5028260 for ; Mon, 26 Mar 2007 15:15:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QMFS8r021596; Tue, 27 Mar 2007 06:15:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ0001B765DU00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 15:15:41 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ004HE765GHB0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 15:15:41 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2QMFcHR261099; Mon, 26 Mar 2007 15:15:38 -0700 (PDT) Date: Mon, 26 Mar 2007 12:15:20 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460841BF.6050105@Sun.Com> To: John Plocher Cc: David.Comay@sun.com, PSARC-EXT@sun.com, Stefan Teleman Message-id: <460845F8.7060202@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> <460838C6.4000604@sun.com> <460841BF.6050105@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 2241 John Plocher wrote: > Joseph Kowalski wrote: >> Either as a TCR, or as a requirement of the case, they don't integrate >> until it happens, so I fail to see what is gained. > > It lets the ARC review reach closure quicker, which is good for all > concerned. Quicker, but unfortunately with a high probability of being wrong. >> I'm not willing to allow a project to integrate with a structure which >> assumes one delivery model which may not be in-line with the Best >> Practice they are asked to deliver. > > Neither am I - go back and reread what I wrote, including the part > where I said > "codifies the ... design pattern that it used". I presume that the > rest of this > review will sort out the specific requirements for that > design-pattern, which > then (by definition) will be in-line with what they need to write about. > > Based on this conversation, I predict that the design pattern will be > either > 1) Do it "Just like Perl" and "Just like Java", or > 2) Don't do it like Perl of Java, instead do it > instead. > > For the life of me, I don't know why you are pushing "door number 2", > but that seems to be your target... I need to check the Perl cases (still), but I don't think there was a Policy. A vaguely remember this was to potentially allow "rolling upgrade",but I'm not sure about this. It ain't gonna be like Java. As I said, it has a lot of infrastructure and motivation I doubt this project team will be willing to take on. (Actually, any project team importing freeware.) Hence, its not that "I'm pushing door number 2". Its that I'm fairly confident that its not "door number 1". (As I said, need to check what we said about Perl.) >> As Advisory, there is no guarantee it ever happens. > > Again, my wording was "TCR - articulate this design pattern", which is > not > an Advisory at all. I'm at an absolute loss as to how you expect us to approve something we haven't seen. Do you regularly hand out blank checks? > The only decoupling I was looking for was the wordsmithing of the BP > itself, > not the determination of the proper design pattern. But its not just wordsmithing into a best practice. Its defining a yet undefined policy. > -John - jek3 From David.Comay@sun.com Mon Mar 26 15:27:21 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QMRLTp028551 for ; Mon, 26 Mar 2007 15:27:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QMR3Uu010277; Mon, 26 Mar 2007 23:27:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ001017PFKV00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 15:27:15 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ004LX7PFGIC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Mar 2007 15:27:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2QMREvQ112529; Mon, 26 Mar 2007 15:27:15 -0700 (PDT) Date: Mon, 26 Mar 2007 15:27:14 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <17928.6057.283590.38555@gargle.gargle.HOWL> Sender: comay@izimbra.SFBay.Sun.COM To: James Carlson Cc: Stefan Teleman , John Plocher , Joseph Kowalski , PSARC-EXT@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <4607FCD3.5060909@Sun.COM> <17928.6057.283590.38555@gargle.gargle.HOWL> Status: RO Content-Length: 771 > 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. I think so. > I somewhat agree with John about the design pattern issue, and I agree > with his "would like to see" comments about pushing the changes back > upstream -- I think the same thing is true in many other projects -- > but I can't see gating integration on any such thing. Absolutely - the general rule is that attempts will be made to push upstream all such changes. I think Stefan was expressing his opinion as to how likely they were to be accepted but the understanding is that all changes will be delivered upstream. dsc From John.Plocher@sun.com Mon Mar 26 15:37:58 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QMbvSE028825 for ; Mon, 26 Mar 2007 15:37:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2QMbHZx001460; Tue, 27 Mar 2007 06:37:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ0020386KEZ00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 15:37:32 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00DBB86JY1D0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 15:37:32 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QMbVo6007504; Mon, 26 Mar 2007 14:37:31 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFJ00I01841JR00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 26 Mar 2007 15:37:31 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFJ007KE86J26M9@d1-sfbay-09.sun.com>; Mon, 26 Mar 2007 15:37:31 -0700 (PDT) Date: Mon, 26 Mar 2007 15:37:28 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460845F8.7060202@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: Stefan Teleman , PSARC-EXT@sun.com Message-id: <46084B28.2060403@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> <460838C6.4000604@sun.com> <460841BF.6050105@Sun.Com> <460845F8.7060202@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 1333 Joseph Kowalski wrote: > John Plocher wrote: >> "codifies the ... design pattern that it used". > I'm at an absolute loss as to how you expect us to approve something we > haven't > seen. Do you regularly hand out blank checks? > But its not just wordsmithing into a best practice. Its defining a yet > undefined policy. I think we are talking at cross purposes, and are in fact in violent agreement. I believe that we both believe that: This set of cases is explicitly setting precedent WRT how to install FOSS components that require the ability to have multiple co-installed versions. /This/ discussion is happening under the php5 topic, but is applicable to the larger SAMPP proposal and all of its sub-components. Future FOSS-derived cases will also have this multi-version install requirement, and so require that this precedent be well articulated and reusable. As part of this review, the details of such a co-install policy will be hammered out. The point of my previous messages was simply that Given that the policy (whatever it is) will be set by this review, the action item to write up that policy and publish it as a best practice can safely be decoupled from the tasks the project team needs to do /this week/. -John From jek3@sun.com Mon Mar 26 15:42:45 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2QMgj2N029068 for ; Mon, 26 Mar 2007 15:42:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2QMgice006380; Mon, 26 Mar 2007 15:42:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFJ002018F8MY00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 15:42:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFJ00DLM8F8XRC0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Mar 2007 15:42:44 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2QMgeri266387; Mon, 26 Mar 2007 15:42:42 -0700 (PDT) Date: Mon, 26 Mar 2007 12:42:26 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46084B28.2060403@Sun.Com> To: John Plocher Cc: Stefan Teleman , PSARC-EXT@sun.com Message-id: <46084C52.2060707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> <460838C6.4000604@sun.com> <460841BF.6050105@Sun.Com> <460845F8.7060202@sun.com> <46084B28.2060403@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1696 Yes, I was wondering about that. The Policy needs to be defined as part of this case. Making it pretty and posting it can be decoupled from this case. The TCR you proposed cleverly makes the "prettifying" the project team's job rather than the default value of "plocher". 8^) - jek3 John Plocher wrote: > Joseph Kowalski wrote: >> John Plocher wrote: >>> "codifies the ... design pattern that it used". > >> I'm at an absolute loss as to how you expect us to approve something >> we haven't >> seen. Do you regularly hand out blank checks? > >> But its not just wordsmithing into a best practice. Its defining a >> yet undefined policy. > > > I think we are talking at cross purposes, and are in fact in violent > agreement. > > I believe that we both believe that: > > This set of cases is explicitly setting precedent WRT how > to install FOSS components that require the ability to have > multiple co-installed versions. > > /This/ discussion is happening under the php5 topic, but is > applicable to the larger SAMPP proposal and all of its > sub-components. > > Future FOSS-derived cases will also have this multi-version > install requirement, and so require that this precedent be > well articulated and reusable. > > As part of this review, the details of such a co-install > policy will be hammered out. > > The point of my previous messages was simply that > > Given that the policy (whatever it is) will be set by this > review, the action item to write up that policy and publish it > as a best practice can safely be decoupled from the tasks > the project team needs to do /this week/. > > -John > > > > From David.Comay@sun.com Tue Mar 27 09:00:58 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2RG0vpo021060 for ; Tue, 27 Mar 2007 09:00:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2RG0YXQ003816; Wed, 28 Mar 2007 00:00:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFK00909KHD6T00@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 09:00:49 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFK000SKKHD2AB0@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 09:00:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2RG0nVw113295; Tue, 27 Mar 2007 09:00:49 -0700 (PDT) Date: Tue, 27 Mar 2007 09:00:48 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <46084B28.2060403@Sun.Com> Sender: comay@izimbra.SFBay.Sun.COM To: John Plocher Cc: Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> <460838C6.4000604@sun.com> <460841BF.6050105@Sun.Com> <460845F8.7060202@sun.com> <46084B28.2060403@Sun.Com> Status: RO Content-Length: 1401 John, > This set of cases is explicitly setting precedent WRT how > to install FOSS components that require the ability to have > multiple co-installed versions. Actually, I thought this case was following the precdent that Perl introduced in PSARC 1999/192. In that case, a directory structure was introduced along the same exact lines as what was proposed here. /usr/perl5/[version]/ > /This/ discussion is happening under the php5 topic, but is > applicable to the larger SAMPP proposal and all of its > sub-components. Isn't this true then of any sort of externally derived open-source? I guess I'm having diffculty seeing what this applies to the proposed SAPP/AMP stack and not the general case of having multiple versions of various open source components. > The point of my previous messages was simply that > > Given that the policy (whatever it is) will be set by this > review, the action item to write up that policy and publish it > as a best practice can safely be decoupled from the tasks > the project team needs to do /this week/. I think it would be fantastic to publish a policy and best practice on how to incorporate externally derived open source into OpenSolaris and I'm more than happy to help create such a document. But I don't see why it is this case's responsibility to write up this policy as part of the case. dsc From Nicolas.Williams@sun.com Tue Mar 27 09:17:06 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2RGH53o021795 for ; Tue, 27 Mar 2007 09:17:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2RGGwn0014824; Tue, 27 Mar 2007 10:17:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFK00I0XL85PW00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 09:16:53 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFK00B2GL84O650@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 09:16:53 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2RGG6Qh000138; Tue, 27 Mar 2007 11:16:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2RGG6AI000137; Tue, 27 Mar 2007 11:16:06 -0500 (CDT) Date: Tue, 27 Mar 2007 11:16:06 -0500 From: Nicolas Williams Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: David.Comay@sun.com Cc: John Plocher , Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: <20070327161605.GL25751@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> <460838C6.4000604@sun.com> <460841BF.6050105@Sun.Com> <460845F8.7060202@sun.com> <46084B28.2060403@Sun.Com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 807 On Tue, Mar 27, 2007 at 09:00:48AM -0700, David.Comay@Sun.COM wrote: > John, > > > This set of cases is explicitly setting precedent WRT how > > to install FOSS components that require the ability to have > > multiple co-installed versions. > > Actually, I thought this case was following the precdent that Perl > introduced in PSARC 1999/192. In that case, a directory structure was > introduced along the same exact lines as what was proposed here. > > /usr/perl5/[version]/ But the OpenSSL cases have set a different precedent. Thus I think a new BP would help. In particular advice on DLL hell avoidance would help (e.g., text in man pages indicating whether it is safe, and how to safely do it, to mix multiple versions of some component in a larger application). Nico -- From David.Comay@sun.com Tue Mar 27 09:26:15 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2RGQEdT022546 for ; Tue, 27 Mar 2007 09:26:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2RGQ7XS010584; Tue, 27 Mar 2007 17:26:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFK00A0XLNJ5S00@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 09:26:07 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFK000DYLNI2AD0@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 09:26:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2RGQ6nl113398; Tue, 27 Mar 2007 09:26:06 -0700 (PDT) Date: Tue, 27 Mar 2007 09:26:06 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <460817E7.5010300@Sun.Com> Sender: comay@izimbra.SFBay.Sun.COM To: John Plocher Cc: Joseph Kowalski , PSARC-EXT@sun.com, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> Status: RO Content-Length: 2016 >> 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 From David.Comay@Sun.COM Tue Mar 27 09:45:24 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2RGjO7q022804 for ; Tue, 27 Mar 2007 09:45:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2RGj6DZ011541; Tue, 27 Mar 2007 09:45:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFK00A0HMJNYZ00@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 09:45:23 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFK00A3BMJMTN00@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 09:45:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2RGjMdt113425; Tue, 27 Mar 2007 09:45:22 -0700 (PDT) Date: Tue, 27 Mar 2007 09:45:21 -0700 (PDT) From: David.Comay@Sun.COM Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <20070326181920.GM25751@Sun.COM> Sender: comay@izimbra.SFBay.Sun.COM To: Nicolas Williams Cc: John Plocher , Joseph Kowalski , PSARC-EXT@Sun.COM, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <20070326181920.GM25751@Sun.COM> Status: RO Content-Length: 753 > Do we preserve /usr/bin/ link replacement on upgrade? I don't believe we do. > Personally I think that customers should not replace /usr/bin/ > links, nor should we support it. The versioning issue exists with or > without OpenSolaris, so customers generally have to [or are better off > if they] reference specific versions of Perl/python/whatever from their > applications rather than generic "latest version" links. > > "Latest version" links are useful for users and developers early on > during development, and for generic scripts that use #! but aren't > "built" and therefore have to use /bin/ in order to have a chance > of running at all. > > We'll probably be better off telling customers as much too. +1 dsc From jek3@sun.com Tue Mar 27 14:04:01 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2RL40EE002560 for ; Tue, 27 Mar 2007 14:04:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2RL3KP4018126; Tue, 27 Mar 2007 15:03:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFK00L01YIHIL00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 14:03:53 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFK00AVLYIGDN50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 14:03:52 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2RL27jn145612; Tue, 27 Mar 2007 14:02:07 -0700 (PDT) Date: Tue, 27 Mar 2007 11:00:03 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: David.Comay@sun.com Cc: John Plocher , PSARC-EXT@sun.com, Stefan Teleman Message-id: <460985D3.3010705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4600AF36.8080407@Sun.COM> <4601A795.7010600@sun.com> <4601AFF1.5070904@Sun.COM> <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <460817E7.5010300@Sun.Com> <46082799.6020500@sun.com> <46082C1B.70707@Sun.Com> <460838C6.4000604@sun.com> <460841BF.6050105@Sun.Com> <460845F8.7060202@sun.com> <46084B28.2060403@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 511 David.Comay@sun.com wrote: > I think it would be fantastic to publish a policy and best practice on > how to incorporate externally derived open source into OpenSolaris and > I'm more than happy to help create such a document. But I don't see > why it is this case's responsibility to write up this policy as part of > the case. Let's put it this way... This case being approved dependent on such a policy existing. Its pretty common for the first explorers of a new territory to take a few arrows. - jek3 From jek3@sun.com Tue Mar 27 17:28:45 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S0SjNr007290 for ; Tue, 27 Mar 2007 17:28:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2S0Sik9027680; Tue, 27 Mar 2007 17:28:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFL004037ZWKM00@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 18:28:44 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL00NQ87ZV1FD0@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 18:28:43 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S0Sgdi176543; Tue, 27 Mar 2007 17:28:42 -0700 (PDT) Date: Tue, 27 Mar 2007 14:28:27 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: David.Comay@sun.com Cc: Nicolas Williams , John Plocher , PSARC-EXT@sun.com, Stefan Teleman Message-id: <4609B6AB.1080204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <20070326181920.GM25751@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1105 David.Comay@Sun.COM wrote: >> Do we preserve /usr/bin/ link replacement on upgrade? > > I don't believe we do. > >> Personally I think that customers should not replace /usr/bin/ >> links, nor should we support it. The versioning issue exists with or >> without OpenSolaris, so customers generally have to [or are better off >> if they] reference specific versions of Perl/python/whatever from their >> applications rather than generic "latest version" links. >> >> "Latest version" links are useful for users and developers early on >> during development, and for generic scripts that use #! but aren't >> "built" and therefore have to use /bin/ in order to have a chance >> of running at all. >> >> We'll probably be better off telling customers as much too. > > +1 > > dsc Do you understand that if the link is Uncommitted, you can only change what it points to at Minor release points. You can't change it to point to the "newer, not known to be compatible" version. From what I've heard about the model so far (and its not enough), I don't see value in a link. - jek3 From David.Comay@sun.com Tue Mar 27 19:57:32 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S2vVBV009710 for ; Tue, 27 Mar 2007 19:57:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2S2vJAV027222; Wed, 28 Mar 2007 10:57:25 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFL00C07EVNYH00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 19:57:23 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL004SYEVN2N50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 19:57:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2S2vMdE114352; Tue, 27 Mar 2007 19:57:23 -0700 (PDT) Date: Tue, 27 Mar 2007 19:57:22 -0700 (PDT) From: David.Comay@sun.com Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4609B6AB.1080204@sun.com> Sender: comay@izimbra.SFBay.Sun.COM To: Joseph Kowalski Cc: Nicolas Williams , John Plocher , PSARC-EXT@sun.com, Stefan Teleman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <20070326181920.GM25751@Sun.COM> <4609B6AB.1080204@sun.com> Status: RO Content-Length: 887 Joe, >> +1 >> >> dsc > Do you understand that if the link is Uncommitted, you can only change > what it points to at Minor release points. You can't change it to point to > the "newer, not known to be compatible" version. Sorry, I was +1'ing the comment by Nico that customers should not be replacing the link themselves. I certainly do understand the restriction around repointing the link only at minor release points (or if a new version is known to be compatible). The intent in Stefan's case was to freeze the version and the link once the minor release is actually delivered. That version and the link can then only be changed in the subsequent minor release. > From what I've heard about the model so far (and its not enough), I don't > see value in a link. What's the reason, then, to ship /usr/bin/java or /usr/bin/perl? I guess I don't quite see the difference. dsc From jek3@sun.com Tue Mar 27 20:23:19 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S3NJ6M010006 for ; Tue, 27 Mar 2007 20:23:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2S3NHuq014591; Tue, 27 Mar 2007 21:23:17 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFL00M0LG2SOY00@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 21:23:16 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL00C7PG2S3YF0@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 21:23:16 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S3NFRE192209; Tue, 27 Mar 2007 20:23:15 -0700 (PDT) Date: Tue, 27 Mar 2007 17:22:59 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: To: David.Comay@sun.com Cc: Nicolas Williams , John Plocher , PSARC-EXT@sun.com, Stefan Teleman Message-id: <4609DF93.70709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <20070326181920.GM25751@Sun.COM> <4609B6AB.1080204@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 2219 David.Comay@sun.com wrote: > Joe, > >>> +1 >>> >>> dsc >> Do you understand that if the link is Uncommitted, you can only change >> what it points to at Minor release points. You can't change it to >> point to >> the "newer, not known to be compatible" version. > > Sorry, I was +1'ing the comment by Nico that customers should not be > replacing the link themselves. > > I certainly do understand the restriction around repointing the link > only at minor release points (or if a new version is known to be > compatible). The intent in Stefan's case was to freeze the version and > the link once the minor release is actually delivered. That version > and the link can then only be changed in the subsequent minor release. OK. Wasn't clear to me. >> From what I've heard about the model so far (and its not enough), I >> don't >> see value in a link. > > What's the reason, then, to ship /usr/bin/java or /usr/bin/perl? I > guess I don't quite see the difference. There are lots of reasons to ship these. Maybe we are talking about different links. The one I'm referring to was only in the discussion, and not the spec. If the link you are talking about is: /usr/bin/foo -> /usr/foostuff/v1.2.3.4/bin/foo there isn't a lot to discuss. If its: /usr/bin/foo -> /etc/foo-redirection/foo /etc/foo-redirection -> /usr/foostuff/v1.2.3.4/bin and foo-redirection is editable, then there is a lot to discuss. Note that the above is the Java model and it was viewed as an exception, rather than a precedent. (Aside: I can't tell you how much I wish the redirection link was in /etc rather than /usr - mucho zone pain.) However, if the links aren't editable (as you seem to be saying), there isn't much issue with any of this. Lot's of i's to dot and t's to cross, but not much more. Best discussed after the model is articulated. Maybe an easier task (rather than a general best practice) would be to articulate why this is like Perl. I still haven't found time to review the Perl decision, but I suspect you may find the reason we did this for Perl was also an exception (one time event) and doesn't apply here. Then again, I'm old enough to have lost many, many neurons, so maybe not. - jek3 From Nicolas.Williams@sun.com Tue Mar 27 21:10:07 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S4A7w8010668 for ; Tue, 27 Mar 2007 21:10:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2S4A20U012985; Wed, 28 Mar 2007 05:10:03 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFL00K03I8PSR00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 21:10:01 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL004CFI8P2MA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Mar 2007 21:10:01 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2S49FxD001941; Tue, 27 Mar 2007 23:09:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2S49FUm001940; Tue, 27 Mar 2007 23:09:15 -0500 (CDT) Date: Tue, 27 Mar 2007 23:09:15 -0500 From: Nicolas Williams Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4609DF93.70709@sun.com> To: Joseph Kowalski Cc: David.Comay@sun.com, John Plocher , PSARC-EXT@sun.com, Stefan Teleman Message-id: <20070328040915.GD1666@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <20070326181920.GM25751@Sun.COM> <4609B6AB.1080204@sun.com> <4609DF93.70709@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3407 On Tue, Mar 27, 2007 at 05:22:59PM -1000, Joseph Kowalski wrote: > David.Comay@sun.com wrote: > >What's the reason, then, to ship /usr/bin/java or /usr/bin/perl? I > >guess I don't quite see the difference. > There are lots of reasons to ship these. > > Maybe we are talking about different links. The one I'm referring to > was only > in the discussion, and not the spec. > > If the link you are talking about is: > /usr/bin/foo -> /usr/foostuff/v1.2.3.4/bin/foo > there isn't a lot to discuss. > > If its: > /usr/bin/foo -> /etc/foo-redirection/foo > /etc/foo-redirection -> /usr/foostuff/v1.2.3.4/bin > and foo-redirection is editable, then there is a lot to discuss. I agree. Customers should have no control over the "default" version of X in _Solaris_ if X is bundled in _Solaris_. Other OpenSolaris distros can do as they please. > Note that the above is the Java model and it was viewed as an exception, > rather > than a precedent. (Aside: I can't tell you how much I wish the redirection > link was in /etc rather than /usr - mucho zone pain.) But that model fits other things that need it for the same reasons as Java. Or is there something really special to Java and, possibly, Perl that there isn't to Python, Ruby, Apache, PHP, etc...? The common thread isn't that they are languages -- they aren't all -- nor that they are OSS -- they weren't all always -- but that for better or for worse they are or we can expect they to ultimately be versioned, and that minor backwards incompatibilities between versions will necessitate temporary, or even permanent bloat, abhorrent though that might be. Nor does not including multiple versions of such things obviate DLL hell -- customers will still have that problem. We might claim that DLL hell isn't our fault if their multiple versions of stuff won't come from Sun, but that's not useful to the customer: DLL hell does not arise from OS vendors' decisions to bundle multiple version of anything, but from the existence of multiple, somewhat backwards incompatible versions of those things in the first place (if we don't ship them then customers will install them from elsewhere). So if DLL hell were a motivating factor (it's been mentioned) for an ARC opinion here then perhaps we could work to setup Best Practice documents that developers of versioned software can follow to minimize DLL hell. The example I gave for C (linking libraries as local groups and not keeping any global state in libraries that might conflict if multiple versions of them are loaded in one process) might be generalizable for other languages, and may lead to advice to developers of run-time environments for various programming languages. > Maybe an easier task (rather than a general best practice) would be to > articulate why this is like Perl. I still haven't found time to review the > Perl decision, but I suspect you may find the reason we did this for > Perl was also an exception (one time event) and doesn't apply here. > Then again, I'm old enough to have lost many, many neurons, so > maybe not. Without looking I find it _hard_ to believe that there is anything particularly special in the case of Perl that does not apply to AMP. I would not count Sun-internal dependencies on multiple versions of Perl as "something special" -- that would seem unfair to customers who develop similar dependencies over time. Nico -- From John.Plocher@sun.com Tue Mar 27 21:12:51 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S4Co08010753 for ; Tue, 27 Mar 2007 21:12:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2S4Cil1024917 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 28 Mar 2007 12:12:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFL00L03IDA3L00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 27 Mar 2007 21:12:46 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL00HBEIDACG90@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 27 Mar 2007 21:12:46 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2S4CkhT027650 for ; Tue, 27 Mar 2007 20:12:46 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFL00J01I96NH00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 27 Mar 2007 21:12:46 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFL007NKIDA2928@d1-sfbay-09.sun.com>; Tue, 27 Mar 2007 21:12:46 -0700 (PDT) Date: Tue, 27 Mar 2007 21:12:42 -0700 From: John Plocher Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <4609DF93.70709@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: PSARC-EXT@sun.com Message-id: <4609EB3A.7070501@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM> <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL> <4602D3CF.8030405@sun.com> <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <20070326181920.GM25751@Sun.COM> <4609B6AB.1080204@sun.com> <4609DF93.70709@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 839 Joseph Kowalski wrote: > Perl decision, but I suspect you may find the reason we did this for > Perl was also an exception (one time event) and doesn't apply here. What do you have against allowing multiple versions of a given component to co-reside in the system? And why should we not reuse and/or update a multi-version model with which we have some experience? I don't think you can argue that we don't need an architecture that supports multiple co-resident versions of a given component in our system, and that we should strive to use it for all instances of the multi-version problem that we come across. I suppose you could argue that SAMPP's components are not ones that should use such an architecture, but I think that that horse is already out of the barn (apache1.3/2.0/2.2.4/..., php4, php5, mysql4, mysql5...) -John From jek3@sun.com Tue Mar 27 22:03:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S53Lgj011919 for ; Tue, 27 Mar 2007 22:03:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2S53DuO010681; Wed, 28 Mar 2007 13:03:15 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFL00909KPB1Z00@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 23:03:11 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL0009WKPAAM90@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 23:03:10 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S539ss200655; Tue, 27 Mar 2007 22:03:09 -0700 (PDT) Date: Tue, 27 Mar 2007 19:02:52 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/168 Including PHP5 with Solaris In-reply-to: <20070328040915.GD1666@Sun.COM> To: Nicolas Williams Cc: David.Comay@sun.com, John Plocher , PSARC-EXT@sun.com, Stefan Teleman Message-id: <4609F6FC.4040609@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8mpCIB7acgzI7ngU1AeE5Q)" X-PMX-Version: 5.2.0.264296 References: <46042E00.9030300@sun.com> <460806F1.6050805@Sun.Com> <20070326181920.GM25751@Sun.COM> <4609B6AB.1080204@sun.com> <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 8163 This is a multi-part message in MIME format. --Boundary_(ID_8mpCIB7acgzI7ngU1AeE5Q) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Nicolas Williams wrote: > But that model fits other things that need it for the same reasons as > Java. Or is there something really special to Java and, possibly, Perl > that there isn't to Python, Ruby, Apache, PHP, etc...? The common > thread isn't that they are languages -- they aren't all -- nor that they > are OSS -- they weren't all always -- but that for better or for worse > they are or we can expect they to ultimately be versioned, and that > minor backwards incompatibilities between versions will necessitate > temporary, or even permanent bloat, abhorrent though that might be. > The special thing about Java is that we'd encouraged, yes ENCOURAGED, ISVs to bundle a private version of Java with their applications. The support for multiple versions WHICH WE COULD PATCH was the special reason. By the time we got this done, the ISVs were willing to It has nothing to depend upon any update in a Minor release series, but they hadn't gained enough confidence to just trust the newest version like they are willing to do with libc. It had nothing to do with it being a language (BTW: You could be shot in Sun for calling Java a language. It is an enviroment. C# and mono are languages. Seriously, be careful about that. Its the major distinguishing feature.) The need to patch became very apparent when indeed a bug in Java showed up where it depended on the pagesize. This caused us to leave a significant performance enhancement (larger page sizes) on the table. Sigh. Lots of dirty laundry here for an open discussion. Keep that in mind next time we get accused of being secretive. Oh heck, its a good story... The Java folk were doing their best to be an ABI compliant application. They thought they were one. They passed all the tests they could find, but those tests pretty much concentrated on functional interfaces. Well, it turns out the ABI allows any power-of-two pagesize between 512 bytes (VAX forever!) and 64k bytes. Unfortunately, the Java Virtual Machine defined an internal stack of 128k bytes and marked the top and bottom pages as unwritable as red zones. Lets see, 128k minus a 64k page at the top and a 64k page at the bottom. Not much left. >> Maybe an easier task (rather than a general best practice) would be to >> articulate why this is like Perl. I still haven't found time to review the >> Perl decision, but I suspect you may find the reason we did this for >> Perl was also an exception (one time event) and doesn't apply here. >> Then again, I'm old enough to have lost many, many neurons, so >> maybe not. >> > > Without looking I find it _hard_ to believe that there is anything > particularly special in the case of Perl that does not apply to AMP. I > would not count Sun-internal dependencies on multiple versions of Perl > as "something special" -- that would seem unfair to customers who > develop similar dependencies over time. > I seem to remember that the special thing about Perl was that we misclassifed an interface too highly. This has been corrected. Hence Perl was a special case to allow fallback because we misled about the stability of (I think) the plug-in interface. I'm hazy about this which is why I haven't said too much until I get a chance to re-examine the Perl case. I think everyone else should also stop talking about the Perl precedent until they re-examine the case to see why this was allowed. Proof by lack of imagination: "I can't imagine why it would be different". Often a dangerous thing. (Credit for the expression: Joe Ekholt.) - jek3 --Boundary_(ID_8mpCIB7acgzI7ngU1AeE5Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Nicolas Williams wrote:
But that model fits other things that need it for the same reasons as
Java.  Or is there something really special to Java and, possibly, Perl
that there isn't to Python, Ruby, Apache, PHP, etc...?  The common
thread isn't that they are languages -- they aren't all -- nor that they
are OSS -- they weren't all always -- but that for better or for worse
they are or we can expect they to ultimately be versioned, and that
minor backwards incompatibilities between versions will necessitate
temporary, or even permanent bloat, abhorrent though that might be.
The special thing about Java is that we'd encouraged, yes ENCOURAGED, ISVs
to bundle a private version of Java with their applications.  The support for multiple
versions WHICH WE COULD PATCH was the special reason.  By the time we got
this done, the ISVs were willing to It has nothing to depend upon any update in a Minor
release series, but they hadn't gained enough confidence to just trust the newest version
like they are willing to do with libc.  It had nothing to do with it being a language
(BTW: You could be shot in Sun for calling Java a language. It is an enviroment.
C# and mono are languages. Seriously, be careful about that. Its the major distinguishing
feature.)

The need to patch became very apparent when indeed a bug in Java showed up
where it depended on the pagesize.  This caused us to leave a significant performance
enhancement (larger page sizes) on the table.  Sigh.

Lots of dirty laundry here for an open discussion.  Keep that in mind next time we
get accused of being secretive.

Oh heck, its a good story... The Java folk were doing their best to be an ABI compliant
application.  They thought they were one.  They passed all the tests they could find, but
those tests pretty much concentrated on functional interfaces.

Well, it turns out the ABI allows any power-of-two pagesize between 512 bytes (VAX
forever!) and 64k bytes.  Unfortunately, the Java Virtual Machine defined an internal
stack of 128k bytes and marked the top and bottom pages as unwritable as red zones.
Lets see, 128k minus a 64k page at the top and a 64k page at the bottom.  Not much
left.

  

    
Maybe an easier task (rather than a general best practice) would be to
articulate why this is like Perl.  I still haven't found time to review the
Perl decision, but I suspect you may find the reason we did this for
Perl was also an exception (one time event) and doesn't apply here.
Then again, I'm old enough to have lost many, many neurons, so
maybe not.
    

  

  

Without looking I find it _hard_ to believe that there is anything
particularly special in the case of Perl that does not apply to AMP.  I
would not count Sun-internal dependencies on multiple versions of Perl
as "something special" -- that would seem unfair to customers who
develop similar dependencies over time.
  



I seem to remember that the special thing about Perl was that we
misclassifed an

interface too highly.  This has been corrected.  Hence Perl was a
special case to

allow fallback because we misled about the stability of (I think) the
plug-in interface.

I'm hazy about this which is why I haven't said too much until I get a
chance

to re-examine the Perl case.  I think everyone else should also stop
talking about

the Perl precedent until they re-examine the case to see why this was
allowed.



Proof by lack of imagination: "I can't imagine why it would be
different". Often

a dangerous thing.  (Credit for the expression: Joe Ekholt.)



- jek3






--Boundary_(ID_8mpCIB7acgzI7ngU1AeE5Q)--

From jek3@SUN.COM Tue Mar 27 22:50:53 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S5oqeR012530
	for ; Tue, 27 Mar 2007 22:50:52 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2S5okTv028049;
	Wed, 28 Mar 2007 13:50:49 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFL0030BMWN3D00@nwk-avmta-2.sfbay.sun.com>; Tue,
 27 Mar 2007 22:50:47 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFL00NW6MWN0Y60@nwk-avmta-2.sfbay.sun.com>; Tue,
 27 Mar 2007 22:50:47 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S5ok69203774;
 Tue, 27 Mar 2007 22:50:46 -0700 (PDT)
Date: Tue, 27 Mar 2007 19:50:30 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4609EB3A.7070501@Sun.Com>
To: John Plocher 
Cc: PSARC-EXT@SUN.COM
Message-id: <460A0226.3050401@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM>
 <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL>
 <4602D3CF.8030405@sun.com> 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <4609EB3A.7070501@Sun.Com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 3583


John,

Interesting tone.

    "What do you have against..."

    "I don't think you can argue..."

We've known each other a very long time, but you'll have to excuse
me if I'm quite blunt in my replies.  (Note to Open folk... I'm not being
a roll model here.)

John Plocher wrote:
> Joseph Kowalski wrote:
>> Perl decision, but I suspect you may find the reason we did this for
>> Perl was also an exception (one time event) and doesn't apply here.
>
> What do you have against allowing multiple versions of a given
> component to co-reside in the system?  And why should we not reuse
> and/or update a multi-version model with which we have some
> experience?
I don't.

Everybody has been saying there is precedent.  I *know* Java is not
the precedent and I suspect Perl isn't a precedent.

Without a precedent, we need all the policy rules written down.  I'm
just asking for them.  Without them, we don't have the foggest idea
what we are doing.  This doesn't come close to the support Java has
for versions (Remember, command line arguments provide version selection,
its not just the path and they allow specification of a range of versions.
As a matter of fact, the paths themselves are Volatile.  If I could have
made them Private, I would have.

You've seen my recollections about Perl.  As I gently suggested to
Nicolas, we should all stop guessing the why's and wherefore's around
Perl and not assume this is a good model until we examine the discussion
which approved this layout for Perl.

Remember, I'm the guy who did the Java stuff.  I didn't get it 100%
right. It is hard.  I have the scars to prove it.
> I don't think you can argue that we don't need an architecture
> that supports multiple co-resident versions of a given component
> in our system, and that we should strive to use it for all instances
> of the multi-version problem that we come across.
I certainly can argue that (not that I am).  I've been at Sun for 17 years
and for the first 14 of those years it was an absolute given that one 
version,
forever upward compatible, was the LAW. It surprises me to hear you
say this, because I think you have been here for 11 or 12 of those 14
years I mention. Times change.  Maybe the rule set should change.
However, I'm not about to do that lightly, because I strongly believe
this old rule set is why GM (Goldman Sacks, whoever) is a heavily
Solaris shop and not a FOSS/Linux shop.  The "deal maker" to one
customer is the "deal breaker" to another.  We must make a thoughtful
and well informed decision here.

What I'm asking for is a Policy and list of criteria to argue about (or 
not).

Without that we are just a bunch of guys who like to hear ourselves talk.
(Apologies to W. Shakespear)
> I suppose you could argue that SAMPP's components are not ones that
> should use such an architecture, but I think that that horse is already
> out of the barn (apache1.3/2.0/2.2.4/..., php4, php5, mysql4, mysql5...)
Humm, I could have sworn I heard one of the leaders of the Apache project
took exception with this, on this very thread.

Note that I've also stated that I had little problem for the support of 
multiple
versions based on Major and known to be incombatible versions (as by the
and mysql examples).  What I am concerned about is supporting multiple
versions because we are either too lazy to test for compatibility or are 
trying
to support applications which depend upon the implementation rather than
the specification.
>   -John
I'l be back once I find time to read the perl case.  I trust I am being 
a roll
model in this regard.

- jek3


From jek3@sun.com Tue Mar 27 22:59:24 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S5xMx4012916
	for ; Tue, 27 Mar 2007 22:59:23 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2S5xCrR000841;
	Wed, 28 Mar 2007 13:59:16 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFL00303NAQII00@nwk-avmta-2.sfbay.sun.com>; Tue,
 27 Mar 2007 22:59:14 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFL00NQGNAQ0Y70@nwk-avmta-2.sfbay.sun.com>; Tue,
 27 Mar 2007 22:59:14 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S5xDIT204326;
 Tue, 27 Mar 2007 22:59:13 -0700 (PDT)
Date: Tue, 27 Mar 2007 19:58:56 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4609F6FC.4040609@sun.com>
To: Joseph Kowalski 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: <460A0420.3090608@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 541

Joseph Kowalski wrote:
> The special thing about Java is that we'd encouraged, yes ENCOURAGED, ISVs
> to bundle a private version of Java with their applications.  The 
> support for multiple
> versions WHICH WE COULD PATCH was the special reason.  By the time we got
> this done, the ISVs were willing to It has nothing to depend upon any 
> update in a Minor
                                                            ^^^^^^^^^^^^^
                                                            Dangling 
extra text. Please ignore.

- jek3


From jek3@sun.com Tue Mar 27 23:03:20 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S63JuV012950
	for ; Tue, 27 Mar 2007 23:03:20 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2S63Ihd008443;
	Tue, 27 Mar 2007 23:03:19 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFL00903NHCYT00@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 27 Mar 2007 23:03:12 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFL0094ENHCL000@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 27 Mar 2007 23:03:12 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S63BTd205055;
 Tue, 27 Mar 2007 23:03:11 -0700 (PDT)
Date: Tue, 27 Mar 2007 20:02:55 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A0420.3090608@sun.com>
To: Joseph Kowalski 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: <460A050F.2070203@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A0420.3090608@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 824

Joseph Kowalski wrote:
> Joseph Kowalski wrote:
>> The special thing about Java is that we'd encouraged, yes ENCOURAGED, 
>> ISVs
>> to bundle a private version of Java with their applications.  The 
>> support for multiple
>> versions WHICH WE COULD PATCH was the special reason.  By the time we 
>> got
>> this done, the ISVs were willing to It has nothing to depend upon any 
>> update in a Minor
>                                                            ^^^^^^^^^^^^^
>                                                            Dangling 
> extra text. Please ignore.
>
> - jek3
Did I mention how much I hate the way mailers (and some other utilities) 
treat tabs.  Sigh.
I'll strongly support any fix to this, regardless of how many versions 
it has.  8^)

The "dangling extra text" is "It has nothing to".

- jek3


From jek3@sun.com Wed Mar 28 01:18:46 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S8Ikfb015536
	for ; Wed, 28 Mar 2007 01:18:46 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2S8HhvA018202;
	Wed, 28 Mar 2007 01:17:47 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFL0040PTPLTC00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 02:17:45 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFL00FAHTPKKV60@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 02:17:44 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S8HhZm214657;
 Wed, 28 Mar 2007 01:17:43 -0700 (PDT)
Date: Tue, 27 Mar 2007 22:17:27 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4609F6FC.4040609@sun.com>
To: Joseph Kowalski 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: <460A2497.2060604@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 4022


The following PSARC cases discuss Perl.

1999/192  Perl                                      Stephen 
Hahn          closed approved fast-track 05/19/99   Mike Shapiro
2000/341  Perl Interface to libexacct               Alan 
Burlison         closed approved fast-track 04/24/02   Andrew Tucker
2001/145  Update of Perl Shipped with Solaris to V  Alan 
Burlison         closed approved fast-track 05/16/01   Andrew Tucker
2001/714  Removal of Perl 5.005_03 from Solaris 10  Alan 
Burlison         closed approved fast-track 11/14/2001 Stephen Hahn
2003/072  Solaris AMP (Apache, MySQL and PHP/Perl/  Paul 
Cunningham       closed withdrawn                      Terrence Miller/Andr
2003/661  Update Perl to version 5.8.x              Alan 
Burlison         closed approved fast-track 12/11/2003 Stephen Hahn
2004/010  Perl interfaces for Solaris Privileges a  Casper 
Dik            closed approved fast-track 01/14/2004 Gary Winiger
2005/462  Removal of Perl 5.6.1 from Solaris 11     Alan 
Burlison         closed approved fast-track 08/03/2005 Stephen Hahn

(Ah, crazy tabs in my mailer again. Sigh.  Why is this so hard?)

The interesting one (IMHO) is 2001/145.  Most of the mail log is an 
exchange between Alan and myself on pretty much the version and 
compatibility issues. Its as I remembered in that the issue was the 
binary module interface. However, I seemed to have made up anything 
about it ever being mis-classified.  I must be confusing it with another 
case.

The basic premise was to provide a rolling upgrade period between the 
Perl versions.  The convience symbolic link was not updated until the 
next Minor release.  The release schedule of Perl was asserted to be 
faster than (and asynchronous to) the release schedule of Solaris, but 
only by enough to result in a couple of versions of Perl on a given 
Solaris release.

So, this is closer to being a precedent for PHP than I suspected, *IF* 
the intent is to support rolling upgrade within a Minor release (of 
Solaris) and to reset to a more current version at Minor release 
points.  (Note 2005/462 above; we seem to be just getting around to this 
in Nevada.) Is this a match? If so, the only thing missing is what are 
the criteria for introducing a new version of PHP5. Examination of the 
Perl case has this, and it doesn't transfer to PHP or anything else. I 
suspect these criteria will be specific for each versioned component we 
add to the system and will need to be supplied in each proposal.

However, it may not be that simple.  The Perl case is quite explicit 
that the "big number" or Major version is thought of as a language 
version and compatibility is very respected in the Perl community.  Is 
this project team prepared to make that same claim for PHP?  Perhaps a 
better way to express this is that Perl required the versioning for one 
interface among many and it was fairly easy to explain what that 
interface is and how to deal with its incompatibility.  What are the set 
of such incompatible interfaces in the PHP stack and can we explain them 
to the user?

I'm not sure what happens if the set of such interfaces is large or not 
easily enumerated. One view is that its simply not appropriate for 
integration into Solaris as anything more than Volatile. Other views are 
possible, but they move us further way from Perl being a precedent. 
Let's cross this bridge if we come to it.

If you read 2001/145, you probably should ignore the details of the 
discussion about the differing semantics of our version scheme and those 
used by many communities.  We have long since decided that we need to 
keep the communities numbers and just document that the user shouldn't 
assign the same properties to it as "native" Solaris version numbers. I 
also make a pejoritive remark about the differing semantics of even and 
odd numbered releases. I still think this is pretty lame (development 
vs. production should be a separate field, IMHO), but I really, really 
don't want to get into that debate here.

- jek3


From Nicolas.Williams@Sun.COM Wed Mar 28 07:14:40 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SEEe3G020900
	for ; Wed, 28 Mar 2007 07:14:40 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SEEbGi020549;
	Wed, 28 Mar 2007 07:14:39 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00E0NA8E9L00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 07:14:38 -0700 (PDT)
Received: from binky.central.sun.com ([129.153.128.104])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM0015MA8EQQC0@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 07:14:38 -0700 (PDT)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2SEDp9p002114;
 Wed, 28 Mar 2007 09:13:51 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2SEDp3F002113; Wed,
 28 Mar 2007 09:13:51 -0500 (CDT)
Date: Wed, 28 Mar 2007 09:13:51 -0500
From: Nicolas Williams 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A2497.2060604@sun.com>
To: Joseph Kowalski 
Cc: David.Comay@Sun.COM, John Plocher ,
        PSARC-EXT@Sun.COM, Stefan Teleman 
Message-id: <20070328141350.GF1666@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <460806F1.6050805@Sun.Com>
  <20070326181920.GM25751@Sun.COM>
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com>
X-Authentication-warning: binky.central.sun.com: nw141292 set sender to
 Nicolas.Williams@sun.com using -f
User-Agent: Mutt/1.5.7i
Status: RO
Content-Length: 488

On Tue, Mar 27, 2007 at 10:17:27PM -1000, Joseph Kowalski wrote:
> The interesting one (IMHO) is 2001/145.  Most of the mail log is an 
> exchange between Alan and myself on pretty much the version and 
> compatibility issues. Its as I remembered in that the issue was the 
> binary module interface. However, I seemed to have made up anything 
> about it ever being mis-classified.  I must be confusing it with another 
> case.

That makes me feel better about my lack of imagination :)

From Stefan.Teleman@sun.com Wed Mar 28 08:43:45 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SFhiPN022689
	for ; Wed, 28 Mar 2007 08:43:45 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SFhPYe008563;
	Wed, 28 Mar 2007 16:43:39 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00803ECPKS00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 08:43:37 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.58.37])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM006C0ECOAZ50@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 08:43:37 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SFhWG7379990; Wed,
 28 Mar 2007 08:43:32 -0700 (PDT)
Date: Wed, 28 Mar 2007 10:42:37 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A2497.2060604@sun.com>
To: Joseph Kowalski 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <460A7EDD.3030504@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 3863

Joseph Kowalski wrote:

> However, it may not be that simple.  The Perl case is quite explicit 
> that the "big number" or Major version is thought of as a language 
> version and compatibility is very respected in the Perl community.  Is 
> this project team prepared to make that same claim for PHP?  Perhaps a 
> better way to express this is that Perl required the versioning for one 
> interface among many and it was fairly easy to explain what that 
> interface is and how to deal with its incompatibility.  What are the set 
> of such incompatible interfaces in the PHP stack and can we explain them 
> to the user?

PHP's Rules Of Engagement seem to be:

1. The PHP Language itself does not have a formal definition. The PHP Language 
itself is defined by each PHP release.

2. No compatibility is assumed, or implied, between Major PHP Releases. PHP4 is 
not compatible with PHP5. Some applications written for PHP4 can be tweaked to 
work with PHP5 with little to moderate effort. Others need substantial rewrites.

3. Breakage can occur within the same Major release. For example, PHP 5.2.0 
(currently being proposed) broke compatiblity with its immediate predecessor, 
PHP 5.1.6.

4. Commrectial usage of PHP does not appear to care too much about keeping track 
of the Latest and Greatest. Once a version of PHP which works well for a given 
application is found, the site tends to stick with it. In many cases, the PHP 
application in question is the money maker for the company, therefore the 
company in question is very reluctant to break it.

5. Longevity of a PHP release is primarily determined by the feature set 
provided by that particular PHP distro. In other words, if we release a PHP 
5.2.0 with _all_ the extensions enabled and fully integrated into Solaris, there 
is very little incentive for a customer to want to upgrade. "Don't fix it if it 
ain't broken".

6. The implication of [5] is that there may be bug and/or security fixes applied 
to later versions of PHP 5.2.x which will not be backported to 5.2.0. This 
implies that we track PHP releases and backport.

7. We could provide a Default Rule Set for our own PHP release and upgrade 
schedule. For example, we could say that we provide one Minor version of PHP for 
each Major PHP release. Example: PHP 5.2.0, PHP 5.3.1, PHP, 5.4.3. We could also 
say that we do not support more than three concurrent versions of PHP at any 
point in time.

8. We could also delegate the responsibility of choosing a particular version of 
PHP to our customer. For example: we have PHP 5.2.0, PHP 5.3.1 and PHP 5.4.3 
installed, with the currently proposed directory scheme. Apache does not care 
which libphp5.so.* is loaded as a module, this is done via httpd.conf && 
friends. Each instance of libphp5.so.* knows how to load its own (and correct) 
PHP Extensions. The customer can choose which particular version of PHP they 
want to use from the three available.

9. The difference, in my mind, between Uncommitted and Volatile is that Volatile 
implies that we could remove or replace components in a binary incompatible 
fashion at any time. I would think that Uncommitted is more appropriate, because 
we do not intend to break PHP in an incompatible manner. We intend to provide 
concurrent different versions of PHP which may be incompatible with each other.

> I'm not sure what happens if the set of such interfaces is large or not 
> easily enumerated.

PHP's set of interfaces is indeed very large. There are several mechanisms by 
which compatibility breakage can occur in PHP, ranging from changes in the 
language itself (caused by a Minor version upgrade), changes in the default 
registration scope of global variables, changes in the optimizer, changes in a 
particular PHP Extension, etc.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From John.Plocher@sun.com Wed Mar 28 09:39:43 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SGdgoQ025681
	for ; Wed, 28 Mar 2007 09:39:43 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SGdXDM027604;
	Wed, 28 Mar 2007 17:39:40 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM0030JGY29T00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 09:39:38 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00I2VGY03B70@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 09:39:37 -0700 (PDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2SGda7s025574; Wed,
 28 Mar 2007 08:39:36 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFM00B01GWCCL00@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Wed,
 28 Mar 2007 09:39:36 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFM007CMGXW293A@d1-sfbay-09.sun.com>; Wed,
 28 Mar 2007 09:39:32 -0700 (PDT)
Date: Wed, 28 Mar 2007 09:39:30 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A7EDD.3030504@Sun.COM>
Sender: John.Plocher@sun.com
To: Stefan Teleman 
Cc: psarc-ext@sun.com
Message-id: <460A9A42.7030706@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 1597

Stefan Teleman wrote:
> 5. Longevity of a PHP release is primarily determined by the feature set 
> provided by that particular PHP distro. In other words, if we release a 
> PHP 5.2.0 with _all_ the extensions enabled and fully integrated into 
> Solaris, there is very little incentive for a customer to want to 
> upgrade. "Don't fix it if it ain't broken".

Don't forget that there are two classes of customer here:

1) The one you identified, that has already settled on a PHP version and
    is reluctant to change  (we are in this camp as well if we allow other
    OpenSolaris projects to depend on a version of PHP...), and

2) The user who has not yet written any code, and who wishes to start
    with the latest version/features.

This seems to imply that

o We (or someone) needs to be able to easily and quickly create a new
   packaged version of the component for OpenSolaris any time the upstream
   community releases new versions (so that this second class of user is
   satisfied), and

o We need to allow our users/admins to select which version(s) that they
   wish to install and/or use (so the more conservative ones are not left
   in the dust).

o We ourselves may need to choose a set of versions to have on the
   system as well (so the dependencies within our distro are satisfied).

I agree with Stefan that we will need three different versions, but for
different reasons:

   A) The latest and greatest
   B) An arbitrary customer-selected historical version, and
   C) A distro-selected version that is used by other components within
      the distro.

    -John

From David.Comay@sun.com Wed Mar 28 10:04:42 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SH4gvA027113
	for ; Wed, 28 Mar 2007 10:04:42 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SH4doA005229;
	Wed, 28 Mar 2007 10:04:41 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00901I3T4300@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 11:04:41 -0600 (MDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM002XII3SI950@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 11:04:41 -0600 (MDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2SH4coT114859;
 Wed, 28 Mar 2007 10:04:38 -0700 (PDT)
Date: Wed, 28 Mar 2007 10:04:38 -0700 (PDT)
From: David.Comay@sun.com
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4609DF93.70709@sun.com>
Sender: comay@izimbra.SFBay.Sun.COM
To: Joseph Kowalski 
Cc: Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM>
 <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL>
 <4602D3CF.8030405@sun.com> 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com>
Status: RO
Content-Length: 430

> If the link you are talking about is:
>   /usr/bin/foo -> /usr/foostuff/v1.2.3.4/bin/foo
> there isn't a lot to discuss.

I believe that's the model here.

> If its:
>   /usr/bin/foo -> /etc/foo-redirection/foo
>   /etc/foo-redirection -> /usr/foostuff/v1.2.3.4/bin
> and foo-redirection is editable, then there is a lot to discuss.

But *that's not* the model being proposed - where did you see that in
Stefan's proposal?

dsc

From jek3@sun.com Wed Mar 28 12:11:31 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SJBUTT005092
	for ; Wed, 28 Mar 2007 12:11:30 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SJBRL2005765;
	Wed, 28 Mar 2007 12:11:30 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00K2HNZ5UH00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 13:11:29 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00JPYNZ4PD00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 13:11:29 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SJBRmE337556;
 Wed, 28 Mar 2007 12:11:27 -0700 (PDT)
Date: Wed, 28 Mar 2007 09:11:06 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070328141350.GF1666@Sun.COM>
To: Nicolas Williams 
Cc: David.Comay@sun.com, John Plocher ,
        PSARC-EXT@sun.com, Stefan Teleman 
Message-id: <460ABDCA.3030704@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_ECYTpQ5vHxMz/QGpwtonVA)"
X-PMX-Version: 5.2.0.264296
References: <460806F1.6050805@Sun.Com>
  <20070326181920.GM25751@Sun.COM>
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <20070328141350.GF1666@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 3133

This is a multi-part message in MIME format.

--Boundary_(ID_ECYTpQ5vHxMz/QGpwtonVA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

Nicolas Williams wrote:
> On Tue, Mar 27, 2007 at 10:17:27PM -1000, Joseph Kowalski wrote:
>   
>> The interesting one (IMHO) is 2001/145.  Most of the mail log is an 
>> exchange between Alan and myself on pretty much the version and 
>> compatibility issues. Its as I remembered in that the issue was the 
>> binary module interface. However, I seemed to have made up anything 
>> about it ever being mis-classified.  I must be confusing it with another 
>> case.
>>     
>
> That makes me feel better about my lack of imagination :)
>   
I understand that.  I'd rather lack imagination than memory.

What were we talking about?  ;-)

I hope that wasn't offensive.  Obviously I was getting a bit ticked off 
last night, mostly
about *any* view that Java is a roll model here. I absolutely know it is 
not and felt
I had said that many times. I was submitter and owner of that case. 
Trust me on
this one.

Anyway, I just always loved that expression of Mr. Eckholt's and it 
seemed to fit.
I've been guilty of it many times myself.

It will take some careful reading to see how much of the Perl work can 
be seen
as valid precedent.

- jek3


--Boundary_(ID_ECYTpQ5vHxMz/QGpwtonVA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT




  


Nicolas Williams wrote:


  
On Tue, Mar 27, 2007 at 10:17:27PM -1000, Joseph Kowalski wrote:
  

  

    
The interesting one (IMHO) is 2001/145.  Most of the mail log is an 
exchange between Alan and myself on pretty much the version and 
compatibility issues. Its as I remembered in that the issue was the 
binary module interface. However, I seemed to have made up anything 
about it ever being mis-classified.  I must be confusing it with another 
case.
    

  

  

That makes me feel better about my lack of imagination :)
  



I understand that.  I'd rather lack imagination than memory.



What were we talking about?   ;-) 



I hope that wasn't offensive.  Obviously I was getting a bit ticked off
last night, mostly

about *any* view that Java is a roll model here. I absolutely know it
is not and felt

I had said that many times. I was submitter and owner of that case.
Trust me on

this one.



Anyway, I just always loved that expression of Mr. Eckholt's and it
seemed to fit.

I've been guilty of it many times myself.



It will take some careful reading to see how much of the Perl work can
be seen

as valid precedent.



- jek3






--Boundary_(ID_ECYTpQ5vHxMz/QGpwtonVA)--

From Nicolas.Williams@sun.com Wed Mar 28 12:15:15 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SJFEUs005177
	for ; Wed, 28 Mar 2007 12:15:14 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SJFDaf000287;
	Wed, 28 Mar 2007 13:15:13 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00H01O5D0400@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 12:15:13 -0700 (PDT)
Received: from binky.central.sun.com ([129.153.128.104])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EL4O5CWN10@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 12:15:12 -0700 (PDT)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2SJEPcf002721;
 Wed, 28 Mar 2007 14:14:25 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2SJEPup002720; Wed,
 28 Mar 2007 14:14:25 -0500 (CDT)
Date: Wed, 28 Mar 2007 14:14:25 -0500
From: Nicolas Williams 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460ABDCA.3030704@sun.com>
To: Joseph Kowalski 
Cc: David.Comay@sun.com, John Plocher ,
        PSARC-EXT@sun.com, Stefan Teleman 
Message-id: <20070328191424.GS1666@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <20070326181920.GM25751@Sun.COM>
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <20070328141350.GF1666@Sun.COM>
 <460ABDCA.3030704@sun.com>
X-Authentication-warning: binky.central.sun.com: nw141292 set sender to
 Nicolas.Williams@sun.com using -f
User-Agent: Mutt/1.5.7i
Status: RO
Content-Length: 1151

On Wed, Mar 28, 2007 at 09:11:06AM -1000, Joseph Kowalski wrote:
> Nicolas Williams wrote:
> >That makes me feel better about my lack of imagination :)
> >  
> I understand that.  I'd rather lack imagination than memory.
> 
> What were we talking about?  ;-)
> 
> I hope that wasn't offensive.  Obviously I was getting a bit ticked off 
> last night, mostly
> about *any* view that Java is a roll model here. I absolutely know it is 
> not and felt
> I had said that many times. I was submitter and owner of that case. 
> Trust me on
> this one.

Well, my "I cannot imagine" comment was specific to the Perl case, not
the Java one.

> Anyway, I just always loved that expression of Mr. Eckholt's and it 
> seemed to fit.
> I've been guilty of it many times myself.
> 
> It will take some careful reading to see how much of the Perl work can 
> be seen
> as valid precedent.

Given what you already wrote it seems like the rationale for multiple
Perl versions applies even more so to PHP and AMP in general.  (And,
frankly, OpenSSL; again, see my comment about DLL hell not going away
as a result of not shipping multiple versions of stuff.)

Nico
-- 

From Stefan.Teleman@sun.com Wed Mar 28 12:43:11 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SJhBI3006226
	for ; Wed, 28 Mar 2007 12:43:11 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SJh93B011850;
	Wed, 28 Mar 2007 12:43:10 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00005PFYAD00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 13:43:10 -0600 (MDT)
Received: from jurassic.eng.sun.com ([129.146.106.31])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00JE8PFWPJ20@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 13:43:09 -0600 (MDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SJh45b401257; Wed,
 28 Mar 2007 12:43:04 -0700 (PDT)
Date: Wed, 28 Mar 2007 14:42:09 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A2497.2060604@sun.com>
To: Joseph Kowalski 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <460AB701.1020600@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 1206

Joseph Kowalski wrote:

> However, it may not be that simple.  The Perl case is quite explicit 
> that the "big number" or Major version is thought of as a language 
> version and compatibility is very respected in the Perl community.  Is 
> this project team prepared to make that same claim for PHP?  Perhaps a 
> better way to express this is that Perl required the versioning for one 
> interface among many and it was fairly easy to explain what that 
> interface is and how to deal with its incompatibility.  What are the set 
> of such incompatible interfaces in the PHP stack and can we explain them 
> to the user?

Question:

If we remove the following symlinks:

/usr/bin/php -> /usr/php5/[version]/bin/php
/usr/lib/libphp5.so -> /usr/php5/[version]/lib/libphp5.so.x.y.z
/etc/php5/php.ini -> /usr/php5/[version]/etc/php.ini

and we only have

/usr/php5/[version]/{bin,lib,modules,share,include,etc}

would this alleviate the concerns about stability level and commitments ?

i do not believe that the user expectation about php being in the default path 
is similar to the expectation about perl or gcc (for example).

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Wed Mar 28 12:45:55 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SJjs95006249
	for ; Wed, 28 Mar 2007 12:45:55 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2SJjeXB015688;
	Thu, 29 Mar 2007 03:45:48 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00I05PK9EC00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 12:45:45 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FIKPK9H430@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 12:45:45 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SJjUOL344319;
 Wed, 28 Mar 2007 12:45:30 -0700 (PDT)
Date: Wed, 28 Mar 2007 09:45:13 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A7EDD.3030504@Sun.COM>
To: Stefan Teleman 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com
Message-id: <460AC5C9.8090500@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 6711


Thanks Stefan, this is good stuff.

Stefan Teleman wrote:
> Joseph Kowalski wrote:
>
>> However, it may not be that simple.  The Perl case is quite explicit 
>> that the "big number" or Major version is thought of as a language 
>> version and compatibility is very respected in the Perl community.  
>> Is this project team prepared to make that same claim for PHP?  
>> Perhaps a better way to express this is that Perl required the 
>> versioning for one interface among many and it was fairly easy to 
>> explain what that interface is and how to deal with its 
>> incompatibility.  What are the set of such incompatible interfaces in 
>> the PHP stack and can we explain them to the user?
>
> PHP's Rules Of Engagement seem to be:
>
> 1. The PHP Language itself does not have a formal definition. The PHP 
> Language itself is defined by each PHP release.
>
> 2. No compatibility is assumed, or implied, between Major PHP 
> Releases. PHP4 is not compatible with PHP5. Some applications written 
> for PHP4 can be tweaked to work with PHP5 with little to moderate 
> effort. Others need substantial rewrites.
I think we are all OK with installation of multiple Major PHP versions 
(at least I am).  There is no expectation of compatibility on
anybody's part.
> 3. Breakage can occur within the same Major release. For example, PHP 
> 5.2.0 (currently being proposed) broke compatiblity with its immediate 
> predecessor, PHP 5.1.6.
>
> 4. Commrectial usage of PHP does not appear to care too much about 
> keeping track of the Latest and Greatest. Once a version of PHP which 
> works well for a given application is found, the site tends to stick 
> with it. In many cases, the PHP application in question is the money 
> maker for the company, therefore the company in question is very 
> reluctant to break it.
>
> 5. Longevity of a PHP release is primarily determined by the feature 
> set provided by that particular PHP distro. In other words, if we 
> release a PHP 5.2.0 with _all_ the extensions enabled and fully 
> integrated into Solaris, there is very little incentive for a customer 
> to want to upgrade. "Don't fix it if it ain't broken".
Which implies to me, that Uncommitted is *too low*.  We don't get to 
clean-up at Minor release points.  My reading of Perl was that we did 
the multiple installations to allow rolling upgrade (which the mail 
trail refers to as turning "flag days into flag periods").  I don't 
think that a customer locking in on a specific PHP version should become 
a reason for the customer to lock in on a OpenSolaris version. Indeed, 
this can be a great problem when a customer buys new equipment (from Sun 
of course) on which to run the application and it not only comes with a 
newer version of Solaris, but older versions can't run on the new 
hardware.  (Note, this isn't only Solaris - I can't load RHEL2-AS on my 
new (SATA) generic x86 hardware.)
> 6. The implication of [5] is that there may be bug and/or security 
> fixes applied to later versions of PHP 5.2.x which will not be 
> backported to 5.2.0. This implies that we track PHP releases and backport.
Maybe I'm missing something here.  Yes, we take on this work (only for 
*serious* issues) if we provide only a single version.  If there are 
multiple versions, we can say "update your application to use the newer 
version".  We often say that for full versions of Solaris for bug fixes 
which are inappropriate to backport.

Of course, security fixes must always be backported.  This could be a 
lot of work (and even more testing) in the case of multiple supported 
versions.
> 7. We could provide a Default Rule Set for our own PHP release and 
> upgrade schedule. For example, we could say that we provide one Minor 
> version of PHP for each Major PHP release. Example: PHP 5.2.0, PHP 
> 5.3.1, PHP, 5.4.3. We could also say that we do not support more than 
> three concurrent versions of PHP at any point in time.
I understand the first part, and yes it provides some model.  Java may 
be an example in this case where we fully support the most current 
Update to each Micro release train.  In other words, 1.4.1_, 
1.4.2_, 1.5.0_ ...

There are a couple attributes of Java that make this work well.  The 
most important of which is that Upgrades within a Micro release family 
not only are very upward compatible, the consumers actually believe and 
trust that they are upward compatible. Doesn't sound like the case 
here.  (Also, Java doesn't intend to do Micro releases anymore, meaning 
that the first digit will *always* be a one (Like in Solaris, its 
*always* a two) and the third digit will always be a zero.  Changes to 
the second digit aren't (yet) full trusted by the consumers while 
changes to the Update ("") are trusted. This all makes it 
relatively simple to explain.)

If the model is to "lock down" on a release, I don't see how we can 
arbitrarily limit the number of instances.

> 8. We could also delegate the responsibility of choosing a particular 
> version of PHP to our customer. For example: we have PHP 5.2.0, PHP 
> 5.3.1 and PHP 5.4.3 installed, with the currently proposed directory 
> scheme. Apache does not care which libphp5.so.* is loaded as a module, 
> this is done via httpd.conf && friends. Each instance of libphp5.so.* 
> knows how to load its own (and correct) PHP Extensions. The customer 
> can choose which particular version of PHP they want to use from the 
> three available.
Sure.  The question is "what do we make available".
> 9. The difference, in my mind, between Uncommitted and Volatile is 
> that Volatile implies that we could remove or replace components in a 
> binary incompatible fashion at any time. I would think that 
> Uncommitted is more appropriate, because we do not intend to break PHP 
> in an incompatible manner. We intend to provide concurrent different 
> versions of PHP which may be incompatible with each other.
Understood.
>> I'm not sure what happens if the set of such interfaces is large or 
>> not easily enumerated.
>
> PHP's set of interfaces is indeed very large. There are several 
> mechanisms by which compatibility breakage can occur in PHP, ranging 
> from changes in the language itself (caused by a Minor version 
> upgrade), changes in the default registration scope of global 
> variables, changes in the optimizer, changes in a particular PHP 
> Extension, etc.
This is an indication that Perl is a poor precedent here. To my reading 
of the Perl discussion, the fact that the fragile interface was easily 
described and that the corrective action was easily described was an 
important part of the approval. Makes "rolling upgrade" fairly easy.
> --Stefan
- jek3


From jek3@sun.com Wed Mar 28 12:59:01 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SJx19B007222
	for ; Wed, 28 Mar 2007 12:59:01 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SJwvvJ008070;
	Wed, 28 Mar 2007 13:58:59 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00L1RQ6B5X00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 12:58:59 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EG5Q6BWN40@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 12:58:59 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SJww5a348208;
 Wed, 28 Mar 2007 12:58:58 -0700 (PDT)
Date: Wed, 28 Mar 2007 09:58:41 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A9A42.7030706@Sun.Com>
To: John Plocher 
Cc: Stefan Teleman , psarc-ext@sun.com
Message-id: <460AC8F1.7000205@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 2018

John Plocher wrote:
> Stefan Teleman wrote:
>> 5. Longevity of a PHP release is primarily determined by the feature 
>> set provided by that particular PHP distro. In other words, if we 
>> release a PHP 5.2.0 with _all_ the extensions enabled and fully 
>> integrated into Solaris, there is very little incentive for a 
>> customer to want to upgrade. "Don't fix it if it ain't broken".
>
> Don't forget that there are two classes of customer here:
>
> 1) The one you identified, that has already settled on a PHP version and
>    is reluctant to change  (we are in this camp as well if we allow other
>    OpenSolaris projects to depend on a version of PHP...), and
>
> 2) The user who has not yet written any code, and who wishes to start
>    with the latest version/features.
>
> This seems to imply that
>
> o We (or someone) needs to be able to easily and quickly create a new
>   packaged version of the component for OpenSolaris any time the upstream
>   community releases new versions (so that this second class of user is
>   satisfied), and
>
> o We need to allow our users/admins to select which version(s) that they
>   wish to install and/or use (so the more conservative ones are not left
>   in the dust).
>
> o We ourselves may need to choose a set of versions to have on the
>   system as well (so the dependencies within our distro are satisfied).
>
> I agree with Stefan that we will need three different versions, but for
> different reasons:
>
>   A) The latest and greatest
>   B) An arbitrary customer-selected historical version, and
>   C) A distro-selected version that is used by other components within
>      the distro.
>
>    -John
Could you say a little more about how you might see B) implemented
appropriate to the available resources?  Also, how does "customer
selected" work?  What are the options available to the customer?

What happens when a customer builds on A, a newer version, A',
becomes available (which happens to be incompatable with A) and
we update to A'?

- jek3


From jek3@sun.com Wed Mar 28 13:01:04 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SK13gi007259
	for ; Wed, 28 Mar 2007 13:01:03 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2SK0sHW020747;
	Thu, 29 Mar 2007 04:00:57 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00J0DQ9I0I00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 13:00:54 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FLEQ9IGS30@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 13:00:54 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SK0r2M348589;
 Wed, 28 Mar 2007 13:00:53 -0700 (PDT)
Date: Wed, 28 Mar 2007 10:00:36 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: David.Comay@sun.com
Cc: Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: <460AC964.90805@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4601C418.4060002@sun.com> <4601C69C.6030506@Sun.COM>
 <4601FF16.2050602@sun.com> <17922.27866.909391.496978@gargle.gargle.HOWL>
 <4602D3CF.8030405@sun.com> 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> 
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 457

David.Comay@sun.com wrote:
>> If its:
>>   /usr/bin/foo -> /etc/foo-redirection/foo
>>   /etc/foo-redirection -> /usr/foostuff/v1.2.3.4/bin
>> and foo-redirection is editable, then there is a lot to discuss.
>
> But *that's not* the model being proposed - where did you see that in
> Stefan's proposal?
I didn't (and pointed that out). I believe I saw it in the mail 
discussion as an
open suggestion.

Anyway, this little edge bit seems resolved.

- jek3


From jek3@sun.com Wed Mar 28 13:06:08 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SK67q7007296
	for ; Wed, 28 Mar 2007 13:06:07 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SK65eJ003865;
	Wed, 28 Mar 2007 13:06:06 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM0020JQI6JH00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 14:06:06 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00JAAQI4P730@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 14:06:04 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SK63KQ350231;
 Wed, 28 Mar 2007 13:06:03 -0700 (PDT)
Date: Wed, 28 Mar 2007 10:05:46 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AB701.1020600@Sun.COM>
To: Stefan Teleman 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com
Message-id: <460ACA9A.2040400@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1638

Stefan Teleman wrote:
> Joseph Kowalski wrote:
>
>> However, it may not be that simple.  The Perl case is quite explicit 
>> that the "big number" or Major version is thought of as a language 
>> version and compatibility is very respected in the Perl community.  
>> Is this project team prepared to make that same claim for PHP?  
>> Perhaps a better way to express this is that Perl required the 
>> versioning for one interface among many and it was fairly easy to 
>> explain what that interface is and how to deal with its 
>> incompatibility.  What are the set of such incompatible interfaces in 
>> the PHP stack and can we explain them to the user?
>
> Question:
>
> If we remove the following symlinks:
>
> /usr/bin/php -> /usr/php5/[version]/bin/php
> /usr/lib/libphp5.so -> /usr/php5/[version]/lib/libphp5.so.x.y.z
> /etc/php5/php.ini -> /usr/php5/[version]/etc/php.ini
>
> and we only have
>
> /usr/php5/[version]/{bin,lib,modules,share,include,etc}
>
> would this alleviate the concerns about stability level and commitments ?
>
> i do not believe that the user expectation about php being in the 
> default path is similar to the expectation about perl or gcc (for 
> example).
>
> --Stefan
Maybe not "alleviate", but certainly simplify the discussions.

We certainly still need to figure out the appropriate commitment to the 
versioned path and when [version]s can be added or removed.

In any case, I think we are best ignoring the "generic names" for the 
moment.  Let's resolve the hard question (about how the versions are to 
be managed) and then look to see if a generic name makes sense in that 
context.

- jek3


From jek3@sun.com Wed Mar 28 13:31:13 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SKVC23008012
	for ; Wed, 28 Mar 2007 13:31:13 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2SKUx2c000518;
	Thu, 29 Mar 2007 04:31:06 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM0010HRNQAK00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 13:31:02 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EEKRNQWO60@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 13:31:02 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SKV1ZE355954;
 Wed, 28 Mar 2007 13:31:01 -0700 (PDT)
Date: Wed, 28 Mar 2007 10:30:44 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070328191424.GS1666@Sun.COM>
To: Nicolas Williams 
Cc: David.Comay@sun.com, John Plocher ,
        PSARC-EXT@sun.com, Stefan Teleman 
Message-id: <460AD074.2020205@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <20070326181920.GM25751@Sun.COM>
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <20070328141350.GF1666@Sun.COM>
 <460ABDCA.3030704@sun.com> <20070328191424.GS1666@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1558

Nicolas Williams wrote:
> On Wed, Mar 28, 2007 at 09:11:06AM -1000, Joseph Kowalski wrote:
>   
>> Nicolas Williams wrote:
>>     
>>> That makes me feel better about my lack of imagination :)
>>>  
>>>       
>> I understand that.  I'd rather lack imagination than memory.
>>
>> What were we talking about?  ;-)
>>
>> I hope that wasn't offensive.  Obviously I was getting a bit ticked off 
>> last night, mostly
>> about *any* view that Java is a roll model here. I absolutely know it is 
>> not and felt
>> I had said that many times. I was submitter and owner of that case. 
>> Trust me on
>> this one.
>>     
>
> Well, my "I cannot imagine" comment was specific to the Perl case, not
> the Java one.
>   

I know.  I was only explaining my "bad mood".
>   
>> Anyway, I just always loved that expression of Mr. Eckholt's and it 
>> seemed to fit.
>> I've been guilty of it many times myself.
>>
>> It will take some careful reading to see how much of the Perl work can 
>> be seen
>> as valid precedent.
>>     
>
> Given what you already wrote it seems like the rationale for multiple
> Perl versions applies even more so to PHP and AMP in general.  (And,
> frankly, OpenSSL; again, see my comment about DLL hell not going away
> as a result of not shipping multiple versions of stuff.)
>   
I don't see it that way.  The Perl case is *so* much simpler and has a 
version
management scheme which seems inappropriate to PHP.

Thinking about OpenSSL should make us all be very leery of opening (pun 
intended)
a potentially worse can of worms.

- jek3


From David.Comay@sun.com Wed Mar 28 14:23:20 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SLNJxq009991
	for ; Wed, 28 Mar 2007 14:23:20 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2SLNA53015838;
	Thu, 29 Mar 2007 05:23:13 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00M05U2NRA00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 14:23:11 -0700 (PDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FPZU2NH160@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 14:23:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2SLNB46115302;
 Wed, 28 Mar 2007 14:23:11 -0700 (PDT)
Date: Wed, 28 Mar 2007 14:23:11 -0700 (PDT)
From: David.Comay@sun.com
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AB701.1020600@Sun.COM>
Sender: comay@izimbra.SFBay.Sun.COM
To: Stefan Teleman 
Cc: Joseph Kowalski ,
        Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM>
Status: RO
Content-Length: 662

> Question:
>
> If we remove the following symlinks:
>
> /usr/bin/php -> /usr/php5/[version]/bin/php
> /usr/lib/libphp5.so -> /usr/php5/[version]/lib/libphp5.so.x.y.z
> /etc/php5/php.ini -> /usr/php5/[version]/etc/php.ini

Actually, this last link is backwards, right?  It should be

/usr/php5/[version]/etc/php.ini -> /etc/php5/php.ini

(and presumedly the delivery of /usr/php5/[version]/etc at all is to
just be consistent with other OSs which delivery PHP, right?)

> and we only have
>
> /usr/php5/[version]/{bin,lib,modules,share,include,etc}

Again, the "etc" subdirectory under /usr/php5/[version] should be at
best, just a symbolic link into /etc.

dsc

From peter.tribble@gmail.com Wed Mar 28 14:34:49 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SLYnqV010981
	for ; Wed, 28 Mar 2007 14:34:49 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SLYmBS021463
	for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 28 Mar 2007 14:34:48 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00705ULZM900@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com
 (ORCPT psarc-ext@sun.com); Wed, 28 Mar 2007 14:34:47 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com ([192.18.43.21])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EI4ULYWFB0@nwk-avmta-1.sfbay.Sun.COM> for
 psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed,
 28 Mar 2007 14:34:46 -0700 (PDT)
Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged))
	by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2SKW68N020231	for
 ; Wed, 28 Mar 2007 21:34:46 +0000 (GMT)
Received: from mms04es.sun.com ([150.143.104.74] [150.143.104.74])
 by relay3.sun.com with ESMTP for psarc-ext@sun.com; Wed,
 28 Mar 2007 21:34:46 +0000 (Z)
Received: from relay01i.sun.com
 (ip70.net150143-60.block3.us.syntegra.com [150.143.60.70])
 by mms04es.sun.com with ESMTP id BT-MMP-88191 for psarc-ext@sun.com; Wed,
 28 Mar 2007 21:34:46 +0000 (Z)
Received: from nz-out-0506.google.com ([64.233.162.236] [64.233.162.236])
 by relay0i.sun.com with ESMTP for psarc-ext@sun.com; Wed,
 28 Mar 2007 21:34:45 +0000 (Z)
Received: by nz-out-0506.google.com with SMTP id m7so2157889nzf for
 ; Wed, 28 Mar 2007 14:34:45 -0700 (PDT)
Received: by 10.65.112.5 with SMTP id p5mr19051246qbm.1175117685524; Wed,
 28 Mar 2007 14:34:45 -0700 (PDT)
Received: by 10.64.220.14 with HTTP; Wed, 28 Mar 2007 14:34:45 -0700 (PDT)
Date: Wed, 28 Mar 2007 21:34:45 +0000
From: Peter Tribble 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A9A42.7030706@Sun.Com>
To: John Plocher 
Cc: Stefan Teleman , psarc-ext@sun.com
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;        d=gmail.com; s=beta;
 h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
 b=aRrtPRrEh8Zlv/2egnS5gKX9awTxhd1WoMpSZQjJ0eNf8pKX2rcNJjqJAT1uzvffTxyFq/tF7vIL0Mg9twY/NdLoMS1GkS30Fp2p0nMp737M3mBvfQAErZnGweRz9558ud+dZANGOPhWW5Shg6HA76y2Yx5BqxzgD9w/XX/RAek=
DomainKey-Signature: a=rsa-sha1; c=nofws;        d=gmail.com; s=beta;
 h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
 b=nHnsPzdHBoawre1hfJkwcq5lGQYWv7DJY8yZMLcoVdR7lPa/BuOowqIZ1HIOfZis70hEysoZFxhyxUjSXCMaZiFMgf/H3jJ4OH1fw9MxKBb3Ei9cof77i1YgHb7IgvYdtyXTw4a3UJNf/5EbUJ73kWiEhXvfkL+NpzEyfoLEgx4=
X-PMX-Version: 5.2.0.264296
References: 
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <460A7EDD.3030504@Sun.COM>
 <460A9A42.7030706@Sun.Com>
Status: RO
Content-Length: 4169

I've been following this thread with interest. Let me wear my
customer hat for a while.

On 3/28/07, John Plocher  wrote:
> Stefan Teleman wrote:
> > 5. Longevity of a PHP release is primarily determined by the feature set
> > provided by that particular PHP distro. In other words, if we release a
> > PHP 5.2.0 with _all_ the extensions enabled and fully integrated into
> > Solaris, there is very little incentive for a customer to want to
> > upgrade. "Don't fix it if it ain't broken".

I agree, up to a point. We've had significant problems with version changes
in underlying components (java, tomcat) causing application breakage. So
if it's not broken, we don't change. The snag is that everything pretty well is
broken and there is often the need to upgrade to a new version.

(As an aside on the benefits of binary compatibility: the FOSS model
used by some applications in which new versions introduce bug fixes and
feature changes simultaneously is a nightmare for production use; it's
unfortunate that it's becoming commonplace. Unfortunately the notion
of "no incompatible change" ends up implying "no bug fixes". But we
all know that already.)

So we need the ability for those underlying components to support both
the ability to rapidly update to a new version if desired, and the ability to
pin a particular version in place for compatibility. And, epecially with zones,
the ability to do both simultaneously on the same system.

Isn't 5.2.1 out already? That's what my systems have been running for a month
or more.

> Don't forget that there are two classes of customer here:
>
> 1) The one you identified, that has already settled on a PHP version and
>     is reluctant to change  (we are in this camp as well if we allow other
>     OpenSolaris projects to depend on a version of PHP...), and
>
> 2) The user who has not yet written any code, and who wishes to start
>     with the latest version/features.

3) The user who has a production system that needs to migrate to the latest
released version for functionality, bugfix, or security reasons.

(And generally, back-porting some subset of those fixes to the "stable"
release picked on isn't a valid solution.)

4) The user who has picked a solution to a problem and requires a
matching version of php to run it on. Or who needs to upgrade such
a solution and needs to upgrade the version of php to match.

> This seems to imply that
>
> o We (or someone) needs to be able to easily and quickly create a new
>    packaged version of the component for OpenSolaris any time the upstream
>    community releases new versions (so that this second class of user is
>    satisfied), and
>
> o We need to allow our users/admins to select which version(s) that they
>    wish to install and/or use (so the more conservative ones are not left
>    in the dust).

Equally, that those who need to keep up with the current release are
able to do so.

> o We ourselves may need to choose a set of versions to have on the
>    system as well (so the dependencies within our distro are satisfied).
>
> I agree with Stefan that we will need three different versions, but for
> different reasons:
>
>    A) The latest and greatest
>    B) An arbitrary customer-selected historical version, and
>    C) A distro-selected version that is used by other components within
>       the distro.

Note that A and B may be the same at some point; and that there may
need to be multiple versions of B.

More generally:

In the case of php, is that aim to supply php as a language or as an
apache module? I've never come across it in use except as an apache
module, so is there any need to put php in the path or php libraries in
/usr/lib?

One thing that causes real problems is connecting application versions to
specific OS releases. The model where the application is frozen on a
minor OS release and then a new version anointed at the next minor release
is unhelpful, indeed harmful. Why should my application be forced to break
or upgrade because I need to migrate to new hardware or access a new
OS feature?

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

From Nicolas.Williams@sun.com Wed Mar 28 14:41:50 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SLfoHO011063
	for ; Wed, 28 Mar 2007 14:41:50 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SLfmqq003720;
	Wed, 28 Mar 2007 14:41:49 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM0080DUXPBI00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 14:41:49 -0700 (PDT)
Received: from binky.central.sun.com ([129.153.128.104])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EY4UXMWDA0@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 14:41:47 -0700 (PDT)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2SLf0O1002936;
 Wed, 28 Mar 2007 16:41:00 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2SLf0Eg002935; Wed,
 28 Mar 2007 16:41:00 -0500 (CDT)
Date: Wed, 28 Mar 2007 16:41:00 -0500
From: Nicolas Williams 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: Peter Tribble 
Cc: John Plocher , psarc-ext@sun.com,
        Stefan Teleman 
Message-id: <20070328214059.GZ1666@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
 
X-Authentication-warning: binky.central.sun.com: nw141292 set sender to
 Nicolas.Williams@sun.com using -f
User-Agent: Mutt/1.5.7i
Status: RO
Content-Length: 638

On Wed, Mar 28, 2007 at 09:34:45PM +0000, Peter Tribble wrote:
> One thing that causes real problems is connecting application versions to
> specific OS releases. The model where the application is frozen on a
> minor OS release and then a new version anointed at the next minor release
> is unhelpful, indeed harmful. Why should my application be forced to break
> or upgrade because I need to migrate to new hardware or access a new
> OS feature?

Worse: forcing you to do that creates incentive for you not to move to
the latest and greatest OS, and that is draining.  There are high costs
in carrying bloat and in not carrying bloat.

From Stefan.Teleman@sun.com Wed Mar 28 14:44:52 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SLipgs011193
	for ; Wed, 28 Mar 2007 14:44:51 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SLimM3026938;
	Wed, 28 Mar 2007 15:44:50 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM0080BV2PK900@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 14:44:49 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.56.36])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EGFV2PWN90@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 14:44:49 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SLiiMK431807; Wed,
 28 Mar 2007 14:44:45 -0700 (PDT)
Date: Wed, 28 Mar 2007 16:43:50 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: David.Comay@sun.com
Cc: Joseph Kowalski ,
        Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <460AD386.3060204@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 1123

David.Comay@sun.com wrote:
>> Question:
>>
>> If we remove the following symlinks:
>>
>> /usr/bin/php -> /usr/php5/[version]/bin/php
>> /usr/lib/libphp5.so -> /usr/php5/[version]/lib/libphp5.so.x.y.z
>> /etc/php5/php.ini -> /usr/php5/[version]/etc/php.ini
> 
> Actually, this last link is backwards, right?  It should be
> 
> /usr/php5/[version]/etc/php.ini -> /etc/php5/php.ini
> 
> (and presumedly the delivery of /usr/php5/[version]/etc at all is to
> just be consistent with other OSs which delivery PHP, right?)
> 
>> and we only have
>>
>> /usr/php5/[version]/{bin,lib,modules,share,include,etc}
> 
> Again, the "etc" subdirectory under /usr/php5/[version] should be at
> best, just a symbolic link into /etc.

IMHO if we remove the symlinks in /usr, i believe we should also remove the 
symlinks in /etc. Given that there will no longer be a php symlink in /usr/bin 
or a libphp5.so symlink in /usr/lib, it is more consistent to have the php 'etc' 
directory contained within the same hierarchy as the rest of each php's version 
release.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From John.Plocher@sun.com Wed Mar 28 14:46:38 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SLkb0j011312
	for ; Wed, 28 Mar 2007 14:46:38 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SLkYa5006811;
	Wed, 28 Mar 2007 22:46:35 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM0000JV5KTR00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 14:46:32 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FGVV5KH280@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 14:46:32 -0700 (PDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2SLkVA0018071; Wed,
 28 Mar 2007 13:46:31 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFM00L01UW04U00@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Wed,
 28 Mar 2007 14:46:31 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFM007O1V5I2BEI@d1-sfbay-09.sun.com>; Wed,
 28 Mar 2007 14:46:30 -0700 (PDT)
Date: Wed, 28 Mar 2007 14:46:27 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AC8F1.7000205@sun.com>
Sender: John.Plocher@sun.com
To: Joseph Kowalski 
Cc: Stefan Teleman , psarc-ext@sun.com
Message-id: <460AE233.4070807@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
 <460AC8F1.7000205@sun.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 1437

Joseph Kowalski wrote:
>> I agree with Stefan that we will need three different versions, but for
>> different reasons:
>>
>>   A) The latest and greatest
>>   B) An arbitrary customer-selected historical version, and
>>   C) A distro-selected version that is used by other components within
>>      the distro.
>>
>>    -John
> Could you say a little more about how you might see B) implemented
> appropriate to the available resources?  Also, how does "customer
> selected" work?  What are the options available to the customer?


The only things I would expect on the install media would be the
latest A and the distro-specific C.  The other versions could be
made available for web download.  If there was a web site that
maintained the set of older versions, any customer who had
standardized on an older version could find it and download it
from there.


> What happens when a customer builds on A, a newer version, A',
> becomes available (which happens to be incompatable with A) and
> we update to A'?

I presume that the "deployed customer" will mostly upgrade their systems
(rather than doing a fresh install).  This implies that upgrade can't
remove A, or overwrite it with A'.

For the deployed user who wants to do a fresh install, there needs to be
a way for them to get and install their specific version (maybe via the
web as above). If all else fails, they could always install it off of
their old OS media.

   -John

From Stefan.Teleman@sun.com Wed Mar 28 14:52:54 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SLqsl4011909
	for ; Wed, 28 Mar 2007 14:52:54 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SLqqNT005950;
	Wed, 28 Mar 2007 14:52:54 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00C49VG5VR00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 15:52:53 -0600 (MDT)
Received: from jurassic.eng.sun.com ([129.146.56.36])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00J9OVG2P780@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 15:52:50 -0600 (MDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SLqjAo431995; Wed,
 28 Mar 2007 14:52:45 -0700 (PDT)
Date: Wed, 28 Mar 2007 16:51:47 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: Peter Tribble 
Cc: John Plocher , psarc-ext@sun.com
Reply-to: Stefan Teleman 
Message-id: <460AD563.2090002@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <460A7EDD.3030504@Sun.COM>
 <460A9A42.7030706@Sun.Com>
 
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 526

Peter Tribble wrote:

> Isn't 5.2.1 out already? That's what my systems have been running for a 
> month or more.

It is indeed out, but i ran into at least one showstopper bug (already reported 
and confirmed at bugs.php.net) (the showstopper bug prevented me from testing 
further). Last i checked the logs for that particular bug, it has been fixed in 
CVS. I would think the fix will be available in 5.2.2.

http://bugs.php.net/bug.php?id=40507

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From David.Comay@sun.com Wed Mar 28 14:59:36 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SLxZMX013373
	for ; Wed, 28 Mar 2007 14:59:36 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2SLxLf6025309;
	Thu, 29 Mar 2007 05:59:29 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00A0FVR22M00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 14:59:26 -0700 (PDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EUWVR1WFC0@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 14:59:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2SLxPE2115387;
 Wed, 28 Mar 2007 14:59:25 -0700 (PDT)
Date: Wed, 28 Mar 2007 14:59:25 -0700 (PDT)
From: David.Comay@sun.com
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AD386.3060204@Sun.COM>
Sender: comay@izimbra.SFBay.Sun.COM
To: Stefan Teleman 
Cc: Joseph Kowalski ,
        Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM>
Status: RO
Content-Length: 609

> IMHO if we remove the symlinks in /usr, i believe we should also remove the 
> symlinks in /etc. Given that there will no longer be a php symlink in 
> /usr/bin or a libphp5.so symlink in /usr/lib, it is more consistent to have 
> the php 'etc' directory contained within the same hierarchy as the rest of 
> each php's version release.

The issue though is configuration files do not belong in /usr.  For
one, Solaris support a read-only /usr and that's the default mode for
diskless clients and non-global zones.  Configration and volatile data
for PHP belongs under /etc and/or /var but never /usr.

dsc

From Stefan.Teleman@sun.com Wed Mar 28 15:04:27 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SM4Q42013537
	for ; Wed, 28 Mar 2007 15:04:27 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2SM4COc027013;
	Thu, 29 Mar 2007 06:04:20 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00A01VZ7LL00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 15:04:19 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.226.130])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00EA8VZ6WFD0@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 15:04:18 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SM4HLn432760; Wed,
 28 Mar 2007 15:04:18 -0700 (PDT)
Date: Wed, 28 Mar 2007 17:03:13 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: David.Comay@sun.com
Cc: Joseph Kowalski ,
        Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <460AD811.2040106@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM> 
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 873



David.Comay@sun.com wrote:
>> IMHO if we remove the symlinks in /usr, i believe we should also 
>> remove the symlinks in /etc. Given that there will no longer be a php 
>> symlink in /usr/bin or a libphp5.so symlink in /usr/lib, it is more 
>> consistent to have the php 'etc' directory contained within the same 
>> hierarchy as the rest of each php's version release.
> 
> The issue though is configuration files do not belong in /usr.  For
> one, Solaris support a read-only /usr and that's the default mode for
> diskless clients and non-global zones.  Configration and volatile data
> for PHP belongs under /etc and/or /var but never /usr.

Then we could clone the /usr model onto /etc:

/etc/php5/[version]/php.ini

and each PHP instance will bind to its own default configuration file.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From John.Plocher@Sun.COM Wed Mar 28 15:08:54 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SM8svw013875
	for ; Wed, 28 Mar 2007 15:08:54 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SM8ouf031792;
	Wed, 28 Mar 2007 16:08:54 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM0010LW6SWK00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 15:08:52 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FXKW6RGWA0@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 15:08:51 -0700 (PDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2SM8pKj020802; Wed,
 28 Mar 2007 14:08:51 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFM00201W5IMH00@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Wed,
 28 Mar 2007 15:08:51 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFM0077BW6Q29EB@d1-sfbay-09.sun.com>; Wed,
 28 Mar 2007 15:08:50 -0700 (PDT)
Date: Wed, 28 Mar 2007 15:08:47 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AD386.3060204@Sun.COM>
Sender: John.Plocher@Sun.COM
To: Stefan Teleman 
Cc: David.Comay@Sun.COM, Joseph Kowalski , PSARC-EXT@Sun.COM
Message-id: <460AE76F.5010307@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 469

Stefan Teleman wrote:
> David.Comay@sun.com wrote:
>> Actually, this last link is backwards, right?  It should be

If you assume that there will only be one active PHP on the system,
then having the php.ini file in /etc is what you want.  If, on the
other hand, you need to have multiple ones running in parallel,
you absolutely don't want this, but instead want the php.ini file to
live alongside the rest of its versioned bits.

I think we need the latter.

   -John

From Stefan.Teleman@sun.com Wed Mar 28 15:53:27 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SMrRPw015374
	for ; Wed, 28 Mar 2007 15:53:27 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SMrQHD022040;
	Wed, 28 Mar 2007 15:53:27 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00303Y92SU00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 15:53:26 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.68.36])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00F5UY92GWE0@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 15:53:26 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SMrP33435346; Wed,
 28 Mar 2007 15:53:25 -0700 (PDT)
Date: Wed, 28 Mar 2007 17:52:27 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AE76F.5010307@Sun.Com>
To: John Plocher 
Cc: David.Comay@sun.com, Joseph Kowalski , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <460AE39B.9030001@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM> <460AE76F.5010307@Sun.Com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 671


John Plocher wrote:
> Stefan Teleman wrote:
>> David.Comay@sun.com wrote:
>>> Actually, this last link is backwards, right?  It should be
> 
> If you assume that there will only be one active PHP on the system,
> then having the php.ini file in /etc is what you want.  If, on the
> other hand, you need to have multiple ones running in parallel,
> you absolutely don't want this, but instead want the php.ini file to
> live alongside the rest of its versioned bits.
> 
> I think we need the latter.

Should we set up a con-call ? Maybe it would be easier to figure this out in 
real-time. :-)

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Wed Mar 28 16:08:10 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SN89Fv016387
	for ; Wed, 28 Mar 2007 16:08:10 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SN7nFq001672;
	Thu, 29 Mar 2007 00:08:06 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00G01YXHR800@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 16:08:05 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FQ6YXGRK00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 16:08:04 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SN7wQv736805;
 Wed, 28 Mar 2007 16:07:58 -0700 (PDT)
Date: Wed, 28 Mar 2007 13:07:41 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AE233.4070807@Sun.Com>
To: John Plocher 
Cc: Stefan Teleman , psarc-ext@sun.com
Message-id: <460AF53D.5030306@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
 <460AC8F1.7000205@sun.com> <460AE233.4070807@Sun.Com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 3045

John Plocher wrote:
> Joseph Kowalski wrote:
>>> I agree with Stefan that we will need three different versions, but for
>>> different reasons:
>>>
>>>   A) The latest and greatest
>>>   B) An arbitrary customer-selected historical version, and
>>>   C) A distro-selected version that is used by other components within
>>>      the distro.
>>>
>>>    -John
>> Could you say a little more about how you might see B) implemented
>> appropriate to the available resources?  Also, how does "customer
>> selected" work?  What are the options available to the customer?
>
>
> The only things I would expect on the install media would be the
> latest A and the distro-specific C.  The other versions could be
> made available for web download.  If there was a web site that
> maintained the set of older versions, any customer who had
> standardized on an older version could find it and download it
> from there.
And the funding for this is coming from where?   :-D

If we have money to throw at this, the absolutely right answer is to bribe
the existing PHP community such that Solaris is a first tier supported
platform.  This can be done many ways, most of which are ethical and
politically correct.  I think the most successful way is to hire one of the
significant PHP maintainers with the job description of "Just as it was,
except you need to make Solaris a first tier platform".

I'm serious about this.  If lots of versions are required, lets not get into
the business of being the middleman. I think customers would be happier
too since it removes latency. I actually really wonder why we don't more
often approach FOSS like we used to approach the ISVs - do something
to make us important.  For larger components it really is the better answer.

If we need one for use of bundled components, we do what RedHat and
others do - install one and stick with it.

Anyway, unless somebody (David?) wants to assert that the kind of money
to support websites with multiple versions (which we support just like the
one on Solaris?) or hire a mole (openly), this seems not to be viable.

Wish it was.  It would truly be nice.

>> What happens when a customer builds on A, a newer version, A',
>> becomes available (which happens to be incompatable with A) and
>> we update to A'?
>
> I presume that the "deployed customer" will mostly upgrade their systems
> (rather than doing a fresh install).  This implies that upgrade can't
> remove A, or overwrite it with A'.
Support love it when a system upgraded != a system installed (to this 
degree).

I guess A would only have a versioned name.  Any kind of genericly named
link screws this up.

A member of the frequent updater program would end up with quite a 
collection
of these, but I guess that's only ugly and not a serious problem.
> For the deployed user who wants to do a fresh install, there needs to be
> a way for them to get and install their specific version (maybe via the
> web as above). If all else fails, they could always install it off of
> their old OS media.
>
>   -John
- jek3


From David.Comay@sun.com Wed Mar 28 16:14:38 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SNEbSt016495
	for ; Wed, 28 Mar 2007 16:14:38 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SNEK8L003973;
	Thu, 29 Mar 2007 00:14:33 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00K0DZ87PX00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 17:14:31 -0600 (MDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00J6NZ86PDE0@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 17:14:30 -0600 (MDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2SNEUoL115509;
 Wed, 28 Mar 2007 16:14:30 -0700 (PDT)
Date: Wed, 28 Mar 2007 16:14:30 -0700 (PDT)
From: David.Comay@sun.com
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AD811.2040106@Sun.COM>
Sender: comay@izimbra.SFBay.Sun.COM
To: Stefan Teleman 
Cc: Joseph Kowalski ,
        Nicolas Williams ,
        John Plocher , psarc-ext@sun.com
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM> 
 <460AD811.2040106@Sun.COM>
Status: RO
Content-Length: 401

> Then we could clone the /usr model onto /etc:
>
> /etc/php5/[version]/php.ini
>
> and each PHP instance will bind to its own default configuration file.

Yes, that makes sense.  But when I asked you about this in an earlier
pre-review, I thought you had said that php.ini only changes between
major versions of PHP (PHP4 vs. PHP5 vs. PHP6) and not between minor
versions.  Did I misunderstand?

dsc

From David.Comay@sun.com Wed Mar 28 16:17:18 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SNHHOL016607
	for ; Wed, 28 Mar 2007 16:17:17 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SNHAcB005111;
	Thu, 29 Mar 2007 00:17:13 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00H0FZCLQC00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 16:17:09 -0700 (PDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FYDZCLRU00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 16:17:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2SNH9Rf115559;
 Wed, 28 Mar 2007 16:17:09 -0700 (PDT)
Date: Wed, 28 Mar 2007 16:17:09 -0700 (PDT)
From: David.Comay@sun.com
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AE76F.5010307@Sun.Com>
Sender: comay@izimbra.SFBay.Sun.COM
To: John Plocher 
Cc: Stefan Teleman , Joseph Kowalski ,
        PSARC-EXT@sun.com
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM> <460AE76F.5010307@Sun.Com>
Status: RO
Content-Length: 711

> If you assume that there will only be one active PHP on the system,
> then having the php.ini file in /etc is what you want.  If, on the
> other hand, you need to have multiple ones running in parallel,
> you absolutely don't want this, but instead want the php.ini file to
> live alongside the rest of its versioned bits.

I don't believe php.ini belongs with the rest of the versioned bits as
it's a configuration file.

I think Stefan's proposal of /etc/php5/[version] which mirrors
/usr/php5/[version] makes the most sense.  Then the question is whether
or not it makes sense to ship a symbolic link

 	/usr/php5/[version]/etc -> /etc/php5/[version]

for "compatibility" with other OS distributions.

dsc

From David.Comay@sun.com Wed Mar 28 16:20:17 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SNKH1H016689
	for ; Wed, 28 Mar 2007 16:20:17 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SNKGC5050459;
	Wed, 28 Mar 2007 17:20:16 -0600 (MDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00L0ZZHRB700@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 17:20:15 -0600 (MDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00J2SZHQP7C0@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 17:20:14 -0600 (MDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2SNKEjv115577;
 Wed, 28 Mar 2007 16:20:14 -0700 (PDT)
Date: Wed, 28 Mar 2007 16:20:14 -0700 (PDT)
From: David.Comay@sun.com
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A2497.2060604@sun.com>
Sender: comay@izimbra.SFBay.Sun.COM
To: Joseph Kowalski 
Cc: Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
Status: RO
Content-Length: 1075

> So, this is closer to being a precedent for PHP than I suspected, *IF* the 
> intent is to support rolling upgrade within a Minor release (of Solaris) and 
> to reset to a more current version at Minor release points.  (Note 2005/462 
> above; we seem to be just getting around to this in Nevada.) Is this a match?

Yes, that was the original intent of Stefan's proposal.

> If so, the only thing missing is what are the criteria for introducing a new 
> version of PHP5. Examination of the Perl case has this, and it doesn't 
> transfer to PHP or anything else. I suspect these criteria will be specific 
> for each versioned component we add to the system and will need to be 
> supplied in each proposal.

Agreed.  In general, I think the criteria will be based on community
demand for an updated version, what features and/or fixes that new
version brings and obviously, what resources are available to bring
that new version forward.

As the intent is to bring some semblance of stability here, I would not
expect that we would be integrating every version.  :-)

dsc

From Stefan.Teleman@Sun.COM Wed Mar 28 16:20:50 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SNKn5g016702
	for ; Wed, 28 Mar 2007 16:20:49 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SNKX9X006181;
	Thu, 29 Mar 2007 00:20:44 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00I0FZIH1K00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 16:20:41 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.224.130])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00F0XZIHRK20@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 16:20:41 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SNKe2c442012; Wed,
 28 Mar 2007 16:20:40 -0700 (PDT)
Date: Wed, 28 Mar 2007 18:19:46 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: David.Comay@Sun.COM
Cc: Joseph Kowalski ,
        Nicolas Williams ,
        John Plocher , psarc-ext@Sun.COM
Reply-to: Stefan Teleman 
Message-id: <460AEA02.1090500@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM> 
 <460AD811.2040106@Sun.COM> 
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 1169



David.Comay@sun.com wrote:
>> Then we could clone the /usr model onto /etc:
>>
>> /etc/php5/[version]/php.ini
>>
>> and each PHP instance will bind to its own default configuration file.
> 
> Yes, that makes sense.  But when I asked you about this in an earlier
> pre-review, I thought you had said that php.ini only changes between
> major versions of PHP (PHP4 vs. PHP5 vs. PHP6) and not between minor
> versions.  Did I misunderstand?

You did not misunderstand -- that is correct. But, that design was based on the 
idea of having, in fact, only one version of php available at a time (due to the 
symlinks in /usr/bin and /usr/lib).

However, given that we are now contemplating the idea of having multiple 
concurrent versions of PHP cohabit on the same system, at the same time, it 
could happen that certain modules, and consequently certain configuration 
directives, are avaliable in one version of PHP, but not another (the actual 
contents of the php.ini file is Volatile). This scenario would suggest that we 
need separate configuration files for each particular PHP version.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From scott.rotondo@sun.com Wed Mar 28 16:26:55 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SNQsqk016819
	for ; Wed, 28 Mar 2007 16:26:54 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SNQqaS007728
	for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 29 Mar 2007 00:26:53 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFM00501ZSSGU00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com
 (ORCPT PSARC-EXT@sun.com); Wed, 28 Mar 2007 16:26:52 -0700 (PDT)
Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFM00FQXZSSGYE0@nwk-avmta-2.sfbay.sun.com> for
 PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed,
 28 Mar 2007 16:26:52 -0700 (PDT)
Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2)
 with ESMTP id l2SNQpM1000204; Wed, 28 Mar 2007 16:26:51 -0700 (PDT)
Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62])
	by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6)
 with ESMTP id l2SNQpT27028; Wed, 28 Mar 2007 16:26:51 -0700 (PDT)
Date: Wed, 28 Mar 2007 16:26:51 -0700
From: Scott Rotondo 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A7EDD.3030504@Sun.COM>
To: Stefan Teleman 
Cc: PSARC-EXT@sun.com
Message-id: <460AF9BB.80402@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM>
User-Agent: Thunderbird 2.0b2 (X11/20070212)
Status: RO
Content-Length: 4308

Stefan Teleman wrote:
> PHP's Rules Of Engagement seem to be:
> 
> 1. The PHP Language itself does not have a formal definition. The PHP 
> Language itself is defined by each PHP release.
> 
> 2. No compatibility is assumed, or implied, between Major PHP Releases. 
> PHP4 is not compatible with PHP5. Some applications written for PHP4 can 
> be tweaked to work with PHP5 with little to moderate effort. Others need 
> substantial rewrites.
> 
> 3. Breakage can occur within the same Major release. For example, PHP 
> 5.2.0 (currently being proposed) broke compatiblity with its immediate 
> predecessor, PHP 5.1.6.
> 
> 4. Commrectial usage of PHP does not appear to care too much about 
> keeping track of the Latest and Greatest. Once a version of PHP which 
> works well for a given application is found, the site tends to stick 
> with it. In many cases, the PHP application in question is the money 
> maker for the company, therefore the company in question is very 
> reluctant to break it.
> 
> 5. Longevity of a PHP release is primarily determined by the feature set 
> provided by that particular PHP distro. In other words, if we release a 
> PHP 5.2.0 with _all_ the extensions enabled and fully integrated into 
> Solaris, there is very little incentive for a customer to want to 
> upgrade. "Don't fix it if it ain't broken".
> 
> 6. The implication of [5] is that there may be bug and/or security fixes 
> applied to later versions of PHP 5.2.x which will not be backported to 
> 5.2.0. This implies that we track PHP releases and backport.
> 
> 7. We could provide a Default Rule Set for our own PHP release and 
> upgrade schedule. For example, we could say that we provide one Minor 
> version of PHP for each Major PHP release. Example: PHP 5.2.0, PHP 
> 5.3.1, PHP, 5.4.3. We could also say that we do not support more than 
> three concurrent versions of PHP at any point in time.
> 
> 8. We could also delegate the responsibility of choosing a particular 
> version of PHP to our customer. For example: we have PHP 5.2.0, PHP 
> 5.3.1 and PHP 5.4.3 installed, with the currently proposed directory 
> scheme. Apache does not care which libphp5.so.* is loaded as a module, 
> this is done via httpd.conf && friends. Each instance of libphp5.so.* 
> knows how to load its own (and correct) PHP Extensions. The customer can 
> choose which particular version of PHP they want to use from the three 
> available.
> 
> 9. The difference, in my mind, between Uncommitted and Volatile is that 
> Volatile implies that we could remove or replace components in a binary 
> incompatible fashion at any time. I would think that Uncommitted is more 
> appropriate, because we do not intend to break PHP in an incompatible 
> manner. We intend to provide concurrent different versions of PHP which 
> may be incompatible with each other.
> 
>> I'm not sure what happens if the set of such interfaces is large or 
>> not easily enumerated.
> 
> PHP's set of interfaces is indeed very large. There are several 
> mechanisms by which compatibility breakage can occur in PHP, ranging 
> from changes in the language itself (caused by a Minor version upgrade), 
> changes in the default registration scope of global variables, changes 
> in the optimizer, changes in a particular PHP Extension, etc.

Wow. That set of constraints and expectations is radically different 
from what we usually encounter for Solaris components. My first reaction 
was "Why on earth would you want to include something like that with the 
operating system?" That's a particularly relevant question if the 
operating system is Solaris, where stability and backward compatibility 
are primary features.

Of course, I know the answer is that we want to make it as easy as 
possible to get started developing PHP code on Solaris. So that suggests 
that the strategy should be: Always include the latest version (for new 
developers to get started), but don't expect existing deployments to use 
it. Expect that customers will download the specific version they want 
from somewhere else.

Under this model, all we have to do is make sure each version installs 
in a uniquely named directory. The system will always come something 
called PHP, and customers can download new ones or delete old ones as 
they see fit.

	Scott


From David.Comay@Sun.COM Wed Mar 28 16:36:06 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SNa6fb017674
	for ; Wed, 28 Mar 2007 16:36:06 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SNa5uR018358;
	Wed, 28 Mar 2007 16:36:06 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN00509085X500@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 16:36:05 -0700 (PDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN00FKQ085H4E0@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 16:36:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2SNa1fT115645;
 Wed, 28 Mar 2007 16:36:01 -0700 (PDT)
Date: Wed, 28 Mar 2007 16:36:01 -0700 (PDT)
From: David.Comay@Sun.COM
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460A9A42.7030706@Sun.Com>
Sender: comay@izimbra.SFBay.Sun.COM
To: John Plocher 
Cc: Stefan Teleman , psarc-ext@Sun.COM
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
Status: RO
Content-Length: 2140

> o We (or someone) needs to be able to easily and quickly create a new
>  packaged version of the component for OpenSolaris any time the upstream
>  community releases new versions (so that this second class of user is
>  satisfied), and

I could understand a desire to do this but that's not the intent of
this project.  The intent is to integrate a stable (to some extent)
version of PHP5 into the project knowing full well that there will
likely be upgrades in the future.  Some of those upgrades may involve
turning on some features in the "existing" PHP5 (for example, adding
MySQL bindings) or incorporating bug fixes to the current version that
don't require a new version.  And some may involve proposing and
getting approval to integrated a newer version of PHP5.

In a future version of Solaris, there might be the multiple trains of
change available that users can choose from - slow (primarily bug
fixes, new features come into view only at well-defined points), medium
(certain classes of features such as platform support come into view)
and fast (constant stream of change, some of it incompatible for
certain commitment levels).

By providing a directory hierarchy like Perl, I believe it can be
leveraged in the future *if* we decide to do that future release.  It
can also be used if we take a more measured approach (what's being
proposed here) and be very selective in which versions of PHP that we
wish to integrate/support.

> o We need to allow our users/admins to select which version(s) that they
>  wish to install and/or use (so the more conservative ones are not left
>  in the dust).

That might be a nice thing to offer but seems outside this case.  We
don't currently do that for any of our other components except perhaps
for their choice of shell or their window system.

The proposed directory structure though does allow different versions
to exist - which ones are integrated depend on which ones the community
proposes, which ones the ARC approves :-) and which ones actually have
the resources behind them to support.  Distro are then free to choose
which of these versions they wish to support.

dsc

From jek3@sun.com Wed Mar 28 17:28:58 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T0Svgc018892
	for ; Wed, 28 Mar 2007 17:28:57 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2T0SkTn011175;
	Thu, 29 Mar 2007 08:28:51 +0800 (SGT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN005212O23300@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 18:28:50 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN003P32O1DK50@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 18:28:50 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2T0Si3h752406;
 Wed, 28 Mar 2007 17:28:45 -0700 (PDT)
Date: Wed, 28 Mar 2007 14:28:28 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: David.Comay@sun.com
Cc: Nicolas Williams ,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: <460B082C.4020309@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1895

David.Comay@sun.com wrote:
>> So, this is closer to being a precedent for PHP than I suspected, 
>> *IF* the intent is to support rolling upgrade within a Minor release 
>> (of Solaris) and to reset to a more current version at Minor release 
>> points.  (Note 2005/462 above; we seem to be just getting around to 
>> this in Nevada.) Is this a match?
>
> Yes, that was the original intent of Stefan's proposal.
>
>> If so, the only thing missing is what are the criteria for 
>> introducing a new version of PHP5. Examination of the Perl case has 
>> this, and it doesn't transfer to PHP or anything else. I suspect 
>> these criteria will be specific for each versioned component we add 
>> to the system and will need to be supplied in each proposal.
>
> Agreed.  In general, I think the criteria will be based on community
> demand for an updated version, what features and/or fixes that new
> version brings and obviously, what resources are available to bring
> that new version forward.
>
> As the intent is to bring some semblance of stability here, I would not
> expect that we would be integrating every version.  :-)
>
> dsc
So, could you update the spec with a paragraph or two to this effect?  
It would seem to
lower the noise level here (who me?).  It would probably be good to 
update it with whatever
you decide to do with the links - I've tried to stay mostly out of that 
discussion until you'all
nailed down a proposal.

It might be good to include in those paragraphs how you are like Perl 
and how you are
not.  I think one significant place you are not is that the potential 
for incompatible
change is the rule rather than the exception.  I think you also need to 
make it clear
that [if] you intend to remove versions at Minor release points (like 
Perl).  This goes
against some of the asserted usage, but I think its critical as to how 
maintainable
this is.

- jek3


From John.Plocher@sun.com Wed Mar 28 17:46:28 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T0kSmF018963
	for ; Wed, 28 Mar 2007 17:46:28 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2T0kRMY011073;
	Wed, 28 Mar 2007 17:46:28 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN0060H3HFHC00@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 18:46:27 -0600 (MDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.5])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN003RJ3HDDKA0@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 18:46:25 -0600 (MDT)
Received: from d1-sfbay-10.sun.com ([192.18.39.120])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2T0kPZE007107; Wed,
 28 Mar 2007 16:46:25 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFN000013BGLW00@d1-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM); Wed,
 28 Mar 2007 17:46:25 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFN00MLB3H7D6T5@d1-sfbay-10.sun.com>; Wed,
 28 Mar 2007 17:46:25 -0700 (PDT)
Date: Wed, 28 Mar 2007 17:46:16 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AF53D.5030306@sun.com>
Sender: John.Plocher@sun.com
To: Joseph Kowalski 
Cc: psarc-ext@sun.com, Stefan Teleman 
Message-id: <460B0C58.6080903@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
 <460AC8F1.7000205@sun.com> <460AE233.4070807@Sun.Com>
 <460AF53D.5030306@sun.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 667

Joseph Kowalski wrote:
> And the funding for this is coming from where?   :-D


This is opensolaris - we have the web site and could host the downloads here.


> If we have money to throw at this, the absolutely right answer is to bribe
> the existing PHP community such that Solaris is a first tier supported
> ...
> Wish it was.  It would truly be nice.

AMEN!


> I guess A would only have a versioned name.  Any kind of genericly named
> link screws this up.


Yup - generic links are bad.


> A member of the frequent updater program would end up with quite a 
> collection


Only if they chose to install the newer versions (full install/upgrade...)

    -John

From John.Plocher@Sun.COM Wed Mar 28 17:53:09 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T0r8hl019003
	for ; Wed, 28 Mar 2007 17:53:09 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2T0r0it027687;
	Thu, 29 Mar 2007 01:53:06 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN007013SIB200@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 18:53:06 -0600 (MDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.5])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN003JV3SHDKC0@brm-avmta-1.central.sun.com>; Wed,
 28 Mar 2007 18:53:05 -0600 (MDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2T0r5SS007561; Wed,
 28 Mar 2007 16:53:05 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFN002013PMMZ00@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Wed,
 28 Mar 2007 17:53:05 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFN007AS3SH26AI@d1-sfbay-09.sun.com>; Wed,
 28 Mar 2007 17:53:05 -0700 (PDT)
Date: Wed, 28 Mar 2007 17:53:01 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
Sender: John.Plocher@Sun.COM
To: David.Comay@Sun.COM
Cc: Stefan Teleman , Joseph Kowalski ,
        psarc-ext@Sun.COM
Message-id: <460B0DED.6030103@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM> <460AE76F.5010307@Sun.Com>
 
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 1328

I misspoke (and, as usual, Stefan said it better anyways :-)

   s/live alongside the rest of its versioned bits/live in a versioned subdirectory of \/etc/

RandyF suggested (in an offline beer-in-hand conversation)
that this could be improved if we simply configured PHP to get its
ini file out of /etc/php5/[version]/php.ini directly and didn't
supply either a link or a default php.ini file in that location.

This would keep php from starting if it wasn't configured (secure
by default-ish) as well as reducing its install-time complexity.

   -John


David.Comay@Sun.COM wrote:
>> If you assume that there will only be one active PHP on the system,
>> then having the php.ini file in /etc is what you want.  If, on the
>> other hand, you need to have multiple ones running in parallel,
>> you absolutely don't want this, but instead want the php.ini file to
>> live alongside the rest of its versioned bits.
> 
> I don't believe php.ini belongs with the rest of the versioned bits as
> it's a configuration file.
> 
> I think Stefan's proposal of /etc/php5/[version] which mirrors
> /usr/php5/[version] makes the most sense.  Then the question is whether
> or not it makes sense to ship a symbolic link
> 
>     /usr/php5/[version]/etc -> /etc/php5/[version]
> 
> for "compatibility" with other OS distributions.
> 
> dsc


From Stefan.Teleman@Sun.COM Wed Mar 28 17:55:44 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T0ti4Z019358
	for ; Wed, 28 Mar 2007 17:55:44 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2T0thRD064117;
	Wed, 28 Mar 2007 18:55:43 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN009033WVW900@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 17:55:43 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.68.130])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN006AT3WUMQ20@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 17:55:42 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2T0tIg9446935; Wed,
 28 Mar 2007 17:55:18 -0700 (PDT)
Date: Wed, 28 Mar 2007 19:54:24 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460B0DED.6030103@Sun.Com>
To: John Plocher 
Cc: David.Comay@Sun.COM, Joseph Kowalski , psarc-ext@Sun.COM
Reply-to: Stefan Teleman 
Message-id: <460B0030.2060400@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460AB701.1020600@Sun.COM> 
 <460AD386.3060204@Sun.COM> <460AE76F.5010307@Sun.Com>
  <460B0DED.6030103@Sun.Com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 866



John Plocher wrote:
> I misspoke (and, as usual, Stefan said it better anyways :-)
> 
>   s/live alongside the rest of its versioned bits/live in a versioned 
> subdirectory of \/etc/
> 
> RandyF suggested (in an offline beer-in-hand conversation)
> that this could be improved if we simply configured PHP to get its
> ini file out of /etc/php5/[version]/php.ini directly and didn't
> supply either a link or a default php.ini file in that location.
> 
> This would keep php from starting if it wasn't configured (secure
> by default-ish) as well as reducing its install-time complexity.

That's exactly what i suggested in my previous email about this -- did that 
email make it through ? i haven't gotten a copy of it (which i should have) and 
i'm wondering if it just never made it.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From John.Plocher@sun.com Wed Mar 28 18:04:23 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T14M2F019610
	for ; Wed, 28 Mar 2007 18:04:22 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2T14A7k029980;
	Thu, 29 Mar 2007 02:04:20 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN00A014B8FJ00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 18:04:20 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN006UN4B7MU20@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 18:04:19 -0700 (PDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2T14JOF008246; Wed,
 28 Mar 2007 17:04:19 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFN00E0149UD500@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Wed,
 28 Mar 2007 18:04:19 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFN0075F4B727AD@d1-sfbay-09.sun.com>; Wed,
 28 Mar 2007 18:04:19 -0700 (PDT)
Date: Wed, 28 Mar 2007 18:04:16 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
Sender: John.Plocher@sun.com
To: David.Comay@sun.com
Cc: PSARC-EXT@sun.com, Stefan Teleman 
Message-id: <460B1090.8020200@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
 
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 1792

David.Comay@Sun.COM wrote:
>> o We (or someone) needs to be able to easily and quickly create a new
>>  packaged version of the component for OpenSolaris any time the upstream
>>  community releases new versions (so that this second class of user is
>>  satisfied), and
> 
> I could understand a desire to do this but that's not the intent of
> this project.  The intent is to integrate a stable (to some extent)

Understood and agreed


> By providing a directory hierarchy like Perl, I believe it can be
> leveraged in the future *if* we decide to do that future release.  It

Great - this is why I was pushing the BestPractice - lets design this
so that we /can/ do that in the future.  As I mentioned to Gina a few
minutes ago, I'm relatively content with how this is playing out, and
have no desire to derail or further impede this case.

>> o We need to allow our users/admins to select which version(s) that they
>>  wish to install and/or use (so the more conservative ones are not left
>>  in the dust).
> 
> That might be a nice thing to offer but seems outside this case.  We
> don't currently do that for any of our other components except perhaps
> for their choice of shell or their window system.

In this case it is clear that users place specific value on the particular
version being used, and that, once installed, are reluctant to upgrade/change.
Forcing them to change will either alienate them or keep them from upgrading,
neither of which seems desirable.  I think we have to acknowledge that including
externally created components like AMPP is significantly different from CDE,
GNOME and ksh93.


> The proposed directory structure though does allow different versions
> to exist...

... and, as I said, I'm happy.  Thanks for working to make this happen!

    -John

From jek3@sun.com Wed Mar 28 18:18:12 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T1IBUW020925
	for ; Wed, 28 Mar 2007 18:18:12 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2T1I7Fv002673;
	Thu, 29 Mar 2007 02:18:08 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN007014Y75E00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 18:18:07 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN00FG24Y6RU60@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 18:18:06 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2T1I5OO758898;
 Wed, 28 Mar 2007 18:18:06 -0700 (PDT)
Date: Wed, 28 Mar 2007 15:17:46 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460B0C58.6080903@Sun.Com>
To: John Plocher 
Cc: psarc-ext@sun.com, Stefan Teleman 
Message-id: <460B13BA.7040500@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
 <460AC8F1.7000205@sun.com> <460AE233.4070807@Sun.Com>
 <460AF53D.5030306@sun.com> <460B0C58.6080903@Sun.Com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 907

John Plocher wrote:
> Joseph Kowalski wrote:
>> And the funding for this is coming from where?   :-D
>
>
> This is opensolaris - we have the web site and could host the 
> downloads here.
The website is fairly cheep.  The cost is in generating and maintaining 
the content.

IMHO, if we have this much to spend, let's use the money to bribe the 
community
into making Solaris important.  (I'm thinking of derailing this just so 
PSARC can
discuss this a bit and see if it is appropriate as Advisory.)  I tend to 
think there is
a lot of "when you only have a hammer, everything looks like a nail" 
associated
with this case.
...
>> A member of the frequent updater program would end up with quite a 
>> collection
>
>
> Only if they chose to install the newer versions (full 
> install/upgrade...)
Should have said "upgrader" rather than "updater" to make my meaning clear.
Probably not important.

- jek3


From jek3@sun.com Wed Mar 28 18:32:59 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T1Wwrn021063
	for ; Wed, 28 Mar 2007 18:32:59 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2T1WjMa005568;
	Thu, 29 Mar 2007 02:32:55 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN008015MTQO00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 18:32:53 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN00ETQ5MTY3E0@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 28 Mar 2007 18:32:53 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2T1Wpqt760436;
 Wed, 28 Mar 2007 18:32:52 -0700 (PDT)
Date: Wed, 28 Mar 2007 15:32:31 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460B1090.8020200@Sun.Com>
To: John Plocher 
Cc: David.Comay@sun.com, PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: <460B172F.5090004@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460A9A42.7030706@Sun.Com>
  <460B1090.8020200@Sun.Com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1507

John Plocher wrote:
> In this case it is clear that users place specific value on the 
> particular
> version being used, and that, once installed, are reluctant to 
> upgrade/change.
> Forcing them to change will either alienate them or keep them from 
> upgrading,
> neither of which seems desirable.  I think we have to acknowledge that 
> including
> externally created components like AMPP is significantly different 
> from CDE,
> GNOME and ksh93.

If there is a significant community that wants this better supported on 
Solaris than
on RedHat, let either the OpenSolaris community or the PHP community do 
that.
Sun can motivate those communities if it is in Sun's best interest.

The problem isn't that locking down on a version will alienate the 
users.  That's
exactly what RedHat (and probably others) do.  The problem is that there 
is an
easy alternate source if you don't like what RedHat delivers.  There doesn't
seem to be a good alternate source if you don't like what Solaris 
delivers.  If this
is important, we need to nurture/motivate that alternate source.

I must be missing something, but I can't make sense of the last 
sentence. Last I
knew CDE, Gnome and ksh93 were all externally created components.  If the
assertion is that all externally created components are not alike, I 
couldn't agree
more.  That's been the basis of much of what I've been saying today and goes
back to the ARC materials generated when we first started bringing FOSS into
Solaris (circa 1999).

- jek3


From Stefan.Teleman@sun.com Wed Mar 28 19:22:55 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2T2MshJ022195
	for ; Wed, 28 Mar 2007 19:22:55 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2T2MsFQ011905;
	Wed, 28 Mar 2007 19:22:54 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFN00E037Y6CI00@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 19:22:54 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.108.31])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFN006UO7Y6MS50@nwk-avmta-2.sfbay.sun.com>; Wed,
 28 Mar 2007 19:22:54 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2T2MnbU453154; Wed,
 28 Mar 2007 19:22:53 -0700 (PDT)
Date: Wed, 28 Mar 2007 22:22:51 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: Peter Tribble 
Cc: John Plocher , psarc-ext@sun.com
Reply-to: Stefan Teleman 
Message-id: <460B22FB.3080802@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <460A7EDD.3030504@Sun.COM>
 <460A9A42.7030706@Sun.Com>
 
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 3552

Peter Tribble wrote:
> I've been following this thread with interest. Let me wear my
> customer hat for a while.
> 
> On 3/28/07, John Plocher  wrote:
>> Stefan Teleman wrote:
>> > 5. Longevity of a PHP release is primarily determined by the feature 
>> set
>> > provided by that particular PHP distro. In other words, if we release a
>> > PHP 5.2.0 with _all_ the extensions enabled and fully integrated into
>> > Solaris, there is very little incentive for a customer to want to
>> > upgrade. "Don't fix it if it ain't broken".
> 
> I agree, up to a point. We've had significant problems with version changes
> in underlying components (java, tomcat) causing application breakage. So
> if it's not broken, we don't change. The snag is that everything pretty 
> well is broken and there is often the need to upgrade to a new version.

Well, yes. Or application  works very well with PHP 5.2.0 but application 
 is miserable with 5.2.0 and happy with 5.3.3 (hypothetically).

This might be a useful argument pro having several versions of PHP available. 
With a little reverse proxy or httpd.conf magic, one could have different 
instances of apache load different versions of PHP.

> (As an aside on the benefits of binary compatibility: the FOSS model
> used by some applications in which new versions introduce bug fixes and
> feature changes simultaneously is a nightmare for production use; it's
> unfortunate that it's becoming commonplace. Unfortunately the notion
> of "no incompatible change" ends up implying "no bug fixes". But we
> all know that already.)
> 
> So we need the ability for those underlying components to support both
> the ability to rapidly update to a new version if desired, and the 
> ability to
> pin a particular version in place for compatibility. And, epecially with 
> zones,
> the ability to do both simultaneously on the same system.
> 
> Isn't 5.2.1 out already? That's what my systems have been running for a 
> month
> or more.

Yes, 5.2.1's been out for a few weeks now but:

http://bugs.php.net/bug.php?id=40507

I ran into this during my testing of 5.2.1 (both 32- and 64- bit), and it was a 
showstopper. I recently saw that it was fixed in CVS. I assume that 5.2.2 will 
have the fix.

> More generally:
> 
> In the case of php, is that aim to supply php as a language or as an
> apache module? I've never come across it in use except as an apache
> module, so is there any need to put php in the path or php libraries in
> /usr/lib?

There will be the apache module [libphp5.so] + php extensions + php the 
executable/language (cli only). I am very reluctant to build the php cgi 
executable. The advantage of php as an apache module is that it's very easy to 
integrate suhosin (http://www.php-security.org/) -- and we will provide suhosin 
from the first release.

> One thing that causes real problems is connecting application versions to
> specific OS releases. The model where the application is frozen on a
> minor OS release and then a new version anointed at the next minor release
> is unhelpful, indeed harmful. Why should my application be forced to break
> or upgrade because I need to migrate to new hardware or access a new
> OS feature?

I think the fundamental problem stems from the long list of dependencies. If 
Nevada 62 (for example) has integrated a whole bunch of these new libraries 
(dependencies), i think it's safe to assume that they will be there going forward.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From John.Plocher@sun.com Thu Mar 29 09:02:34 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2TG2X9R008239
	for ; Thu, 29 Mar 2007 09:02:33 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2TG2W2V028858;
	Thu, 29 Mar 2007 10:02:33 -0600 (MDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFO0031H9W7AX00@brm-avmta-1.central.sun.com>; Thu,
 29 Mar 2007 10:02:31 -0600 (MDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.6])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFO00BK29W6Z3D0@brm-avmta-1.central.sun.com>; Thu,
 29 Mar 2007 10:02:30 -0600 (MDT)
Received: from d1-sfbay-10.sun.com ([192.18.39.120])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2TG2TwV027275; Thu,
 29 Mar 2007 08:02:29 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFO004019TO4P00@d1-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM); Thu,
 29 Mar 2007 09:02:29 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFO00MQ79W5D79C@d1-sfbay-10.sun.com>; Thu,
 29 Mar 2007 09:02:29 -0700 (PDT)
Date: Thu, 29 Mar 2007 09:02:26 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
Sender: John.Plocher@sun.com
To: Peter Tribble 
Cc: Stefan Teleman , psarc-ext@sun.com
Message-id: <460BE312.1080203@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
  <4609B6AB.1080204@sun.com>
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <460A7EDD.3030504@Sun.COM>
 <460A9A42.7030706@Sun.Com>
 
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 3493

Peter Tribble wrote:
> So we need the ability for those underlying components to support both
> the ability to rapidly update to a new version if desired, and the 
> ability to
> pin a particular version in place for compatibility. And, epecially with 
> zones,
> the ability to do both simultaneously on the same system.

In your opinion, does the current updated proposal meet these needs?
I think it does, but I'd like to make sure you do as well.


> [Peter added more user types]
> 3) The user who has a production system that needs to migrate to the latest
> released version for functionality, bugfix, or security reasons.
> 
> (And generally, back-porting some subset of those fixes to the "stable"
> release picked on isn't a valid solution.)
> 
> 4) The user who has picked a solution to a problem and requires a
> matching version of php to run it on. Or who needs to upgrade such
> a solution and needs to upgrade the version of php to match.

I /think/ that both of these needs are met if we continue to track
a reasonable approximation of the latest stable community release.
As Joe said, the best of all worlds is if the PHP community were to
be the issuer for these packages, but it is also OK for some part of
the OS.o community to do so instead.  Does this match your understanding?


>> I agree with Stefan that we will need three different versions, but for
>> different reasons:
>>
>>    A) The latest and greatest
>>    B) An arbitrary customer-selected historical version, and
>>    C) A distro-selected version that is used by other components within
>>       the distro.
> 
> Note that A and B may be the same at some point; and that there may
> need to be multiple versions of B.

Of course - I tend to be overly terse in some places and the opposite in others...

> In the case of php, is that aim to supply php as a language or as an
> apache module? I've never come across it in use except as an apache
> module, so is there any need to put php in the path or php libraries in
> /usr/lib?


I think the majority use is in web pages, but there are development test
scenerios that use the command line.  I don't think (and I don't wish to
have) the command line interface to php needs to be in /usr/bin.


> 
> One thing that causes real problems is connecting application versions to
> specific OS releases. The model where the application is frozen on a
> minor OS release and then a new version anointed at the next minor release
> is unhelpful, indeed harmful. Why should my application be forced to break
> or upgrade because I need to migrate to new hardware or access a new
> OS feature?


I very much agree with this.  Not all components of OpenSolaris share
the same release taxonomy binding; in particular, the SFW consolidation
is relatively free to do major releases as it sees fit; ON on the other
hand would probably choose the stability that a minor release path would
provide...

A pet peeve of mine is when people assign a release taxonomy to a product
instead of its components - for example, stating that Solaris10 is a minor
release. Bullpucky!  The Solaris 10 vinyl binder contains ON (a minor
release), Java (another minor release), SFW (lots of volatile FOSS stuff),
the companion CD (major releases all the way!), NetBeans (major release),
try-and-buy database teasers (major releases there, too). etc  Lets not
fall into the trap of paonting all our OS.o components with the same "ON"
brush.


  -John


From bart.smaalders@Sun.COM Fri Mar 30 16:29:43 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2UNTg71022911
	for ; Fri, 30 Mar 2007 16:29:42 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2U1PEY0026759
	for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@Sun.COM>; Fri, 30 Mar 2007 09:25:23 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFO00B05ZY9C600@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM
 (ORCPT PSARC-EXT@Sun.COM); Thu, 29 Mar 2007 18:25:21 -0700 (PDT)
Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFO0038QZY99K60@nwk-avmta-2.sfbay.sun.com> for
 PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu,
 29 Mar 2007 18:25:21 -0700 (PDT)
Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75])
	by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l2U1PKMI023142; Thu, 29 Mar 2007 18:25:20 -0700 (PDT)
Received: from [129.146.228.109] (cyber [129.146.228.109])
	by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2U1PKfV018753; Thu,
 29 Mar 2007 18:25:20 -0700 (PDT)
Date: Thu, 29 Mar 2007 18:24:24 -0700
From: Bart Smaalders 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
To: PSARC-EXT@Sun.COM
Cc: Stefan Teleman 
Message-id: <460C66C8.602@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
User-Agent: Thunderbird 2.0b2 (X11/20070227)
Status: RO
Content-Length: 241

An updated copy of the fast track with corrections
(case numbers, 64 bit paths, etc) has been placed in
the materials subdirectory.

- Bart

-- 
Bart Smaalders			Solaris Kernel Performance
barts@cyber.eng.sun.com		http://blogs.sun.com/barts

From Alan.Burlison@sun.com Fri Mar 30 16:29:44 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2UNThY4022912
	for ; Fri, 30 Mar 2007 16:29:43 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2U97XlI014550;
	Fri, 30 Mar 2007 17:07:36 +0800 (SGT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFP00A03LCMIS00@brm-avmta-1.central.sun.com>; Fri,
 30 Mar 2007 03:07:34 -0600 (MDT)
Received: from nis-uk.uk.sun.com ([129.156.85.41])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFP00DWRLCLDN90@brm-avmta-1.central.sun.com>; Fri,
 30 Mar 2007 03:07:33 -0600 (MDT)
Received: from barman.uk.sun.com (barman [129.156.132.12])
	by nis-uk.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l2U97S9d022226; Fri, 30 Mar 2007 10:07:29 +0100 (BST)
Received: from vpn-129-150-120-89.uk.sun.com ([129.150.120.89])
	by barman.uk.sun.com with esmtp (Exim 4.42)	id 1HXDE0-0004kW-UT; Fri,
 30 Mar 2007 10:16:49 +0100
Date: Fri, 30 Mar 2007 11:07:29 +0100
From: Alan Burlison 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460AC5C9.8090500@sun.com>
To: Joseph Kowalski 
Cc: Stefan Teleman ,
        Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com
Message-id: <460CE161.6080006@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460AC5C9.8090500@sun.com>
User-Agent: Thunderbird 2.0b2 (X11/20070227)
Status: RO
Content-Length: 465

Joseph Kowalski wrote:

> My reading of Perl was that we did 
> the multiple installations to allow rolling upgrade (which the mail 
> trail refers to as turning "flag days into flag periods").

Correct.  A customer should always be able to upgrade to Solaris+1 
without forcing them to switch perl version.  They then have until 
Solaris+2 to migrate, at which point the oldest of the 2 versions of 
perl that we ship will have been removed.

-- 
Alan Burlison
--

From Alan.Burlison@sun.com Fri Mar 30 16:58:41 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2UNwfIq024220
	for ; Fri, 30 Mar 2007 16:58:41 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2U8wnIg015192;
	Fri, 30 Mar 2007 01:58:50 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFP0090LKY1NI00@brm-avmta-1.central.sun.com>; Fri,
 30 Mar 2007 02:58:49 -0600 (MDT)
Received: from nis-uk.uk.sun.com ([129.156.85.41])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFP00DO9KY0DV80@brm-avmta-1.central.sun.com>; Fri,
 30 Mar 2007 02:58:48 -0600 (MDT)
Received: from barman.uk.sun.com (barman [129.156.132.12])
	by nis-uk.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l2U8wcI8017720; Fri, 30 Mar 2007 09:58:38 +0100 (BST)
Received: from vpn-129-150-120-89.uk.sun.com ([129.150.120.89])
	by barman.uk.sun.com with esmtp (Exim 4.42)	id 1HXD5S-0004id-Hw; Fri,
 30 Mar 2007 10:07:58 +0100
Date: Fri, 30 Mar 2007 10:58:38 +0100
From: Alan Burlison 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4609F6FC.4040609@sun.com>
To: Joseph Kowalski 
Cc: Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com,
        Stefan Teleman 
Message-id: <460CDF4E.60706@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com>
User-Agent: Thunderbird 2.0b2 (X11/20070227)
Status: RO
Content-Length: 3077

Joseph Kowalski wrote:

> I seem to remember that the special thing about Perl was that we 
> misclassifed an
> interface too highly.  This has been corrected.  Hence Perl was a 
> special case to
> allow fallback because we misled about the stability of (I think) the 
> plug-in interface.
> I'm hazy about this which is why I haven't said too much until I get a 
> chance
> to re-examine the Perl case.  I think everyone else should also stop 
> talking about
> the Perl precedent until they re-examine the case to see why this was 
> allowed.

For the purposes of discussion perl can be thought of as having 2 
interfaces, one is the 'script-level' interface and the other is the 
'C-level' or more correctly the 'XSUB-level'.  Perl-only modules on CPAN 
consume the first interface, modules with a C component consume the second.

The perl-level interface is stable and backwards-compatible across releases.

The XSUB-level interface consists of a series of C functions and macros, 
the implementation of which may change between releases (although the 
code-level interface is stable).  Although a XSUB module compiled 
against a previous version of perl *may* work with the next version, it 
isn't guaranteed, and it is safest to recompile any such modules against 
the later version.

At present, the only packages we deliver, and that therefore other 
things which require perl can express packaging dependencies on are 
these packages:

SUNWpl5m                           Perl 5.6.1 Reference Manual Pages
SUNWpl5p                           Perl 5.6.1 (POD Documentation)
SUNWpl5u                           Perl 5.6.1 (core)
SUNWpl5v                           Perl 5.6.1 (non-core)
SUNWperl584core                    Perl 5.8.4 (core)
SUNWperl584man                     Perl 5.8.4 Reference Manual Pages
SUNWperl584usr                     Perl 5.8.4 (non-core)

Before we got long package names we had to do a horrid packaging dance 
(is there any other kind?) each time we upgraded - the existing packages 
were renamed from SUNWpl* to SUNWopl5, and the new packages were given 
the SUNWpl* names.

Currently, if a package needs perl it has to express a dependency on 
SUNWperl584core and SUNWperl584usr.  However, that ties it to a specific 
version of perl.  That's what is required for packages that consume the 
perl XSUB-level interface, but it means that packages which only use the 
perl script-level interface are unnecessarily bound to a specific 
version of perl, when any later-but-compatible version would be fine.

Bugid 6309711 "Perl should deliver a stable package for dependents to 
depend on" addresses this issue.  The intention is to provide a new 
package, SUNWperl5 which will just contain the symlinks under /usr that 
point to the latest version of perl.  Packages which consume the perl 
script-only interface can express a dependency on SUNWperl5 and will 
therefore be unaffected by perl version upgrades.  Packages which 
consume the XSUB interface will still be dependent on the 
version-specific packages as before.

-- 
Alan Burlison
--

From John.Plocher@sun.com Fri Mar 30 17:09:10 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2V0997K024297
	for ; Fri, 30 Mar 2007 17:09:09 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2V08fPL002852
	for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Sat, 31 Mar 2007 01:08:41 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFQ00F01R2H3L00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com
 (ORCPT PSARC-EXT@sun.com); Fri, 30 Mar 2007 17:08:41 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFQ007DWR2HP430@nwk-avmta-1.sfbay.Sun.COM> for
 PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri,
 30 Mar 2007 17:08:41 -0700 (PDT)
Received: from d1-sfbay-10.sun.com ([192.18.39.120])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2V08fom024640	for
 ; Fri, 30 Mar 2007 16:08:41 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JFQ00K01R0VJU00@d1-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri,
 30 Mar 2007 17:08:41 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JFQ00MRKR2GD6DB@d1-sfbay-10.sun.com> for PSARC-EXT@sun.com
 (ORCPT PSARC-EXT@sun.com); Fri, 30 Mar 2007 17:08:40 -0700 (PDT)
Date: Fri, 30 Mar 2007 17:08:35 -0700
From: John Plocher 
Subject: Test Message - IGNORE  Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460CDF4E.60706@sun.com>
Sender: John.Plocher@sun.com
To: John.Plocher@sun.com
Cc: PSARC-EXT@sun.com
Message-id: <460DA683.1030403@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460CDF4E.60706@sun.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 154

[We just upgraded the hardware for the sun-internal ARC server]

This is a test of the email infrastructure - please ignore (and don't reply)

    -John


From jek3@sun.com Fri Mar 30 17:49:12 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2V0nBPc024434
	for ; Fri, 30 Mar 2007 17:49:12 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2V0mas3009552;
	Sat, 31 Mar 2007 01:48:39 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFQ00901SX2N300@brm-avmta-1.central.sun.com>; Fri,
 30 Mar 2007 18:48:38 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFQ0009ESX2TTF0@brm-avmta-1.central.sun.com>; Fri,
 30 Mar 2007 18:48:38 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2V0matv484681;
 Fri, 30 Mar 2007 17:48:37 -0700 (PDT)
Date: Fri, 30 Mar 2007 14:48:15 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460CE161.6080006@sun.com>
To: Alan Burlison 
Cc: Stefan Teleman ,
        Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com
Message-id: <460DAFCF.3090509@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460AC5C9.8090500@sun.com>
 <460CE161.6080006@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 702

Alan Burlison wrote:
> Joseph Kowalski wrote:
>
>> My reading of Perl was that we did the multiple installations to 
>> allow rolling upgrade (which the mail trail refers to as turning 
>> "flag days into flag periods").
>
> Correct.  A customer should always be able to upgrade to Solaris+1 
> without forcing them to switch perl version.  They then have until 
> Solaris+2 to migrate, at which point the oldest of the 2 versions of 
> perl that we ship will have been removed.
Of course, the flaw here is many of our customer do upgrade, but skip 
releases (old data: circa 5.5-5.8), so this doesn't work for them.

That said, I'm comfortable with the approach.  We gave them a viable path.

- jek3


From Alan.Burlison@sun.com Fri Mar 30 23:31:10 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2V6VAJE001270
	for ; Fri, 30 Mar 2007 23:31:10 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2V6TxON008121;
	Fri, 30 Mar 2007 23:29:59 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFR008038PZIU00@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 30 Mar 2007 23:29:59 -0700 (PDT)
Received: from nis-uk.uk.sun.com ([129.156.85.41]) by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFR004C88PYMS60@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 30 Mar 2007 23:29:59 -0700 (PDT)
Received: from barman.uk.sun.com (barman [129.156.132.12])
	by nis-uk.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l2V6TrJp022252; Sat, 31 Mar 2007 07:29:53 +0100 (BST)
Received: from vpn-129-150-120-89.uk.sun.com ([129.150.120.89])
	by barman.uk.sun.com with esmtp (Exim 4.42)	id 1HXXF4-00061R-JD; Sat,
 31 Mar 2007 07:39:14 +0100
Date: Sat, 31 Mar 2007 08:29:55 +0100
From: Alan Burlison 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460DAFCF.3090509@sun.com>
To: Joseph Kowalski 
Cc: Stefan Teleman ,
        Nicolas Williams , David.Comay@sun.com,
        John Plocher , PSARC-EXT@sun.com
Message-id: <460E0DF3.5040907@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
 <46042E00.9030300@sun.com> 
 <460806F1.6050805@Sun.Com> 
 <20070326181920.GM25751@Sun.COM> 
 <4609B6AB.1080204@sun.com> 
 <4609DF93.70709@sun.com> <20070328040915.GD1666@Sun.COM>
 <4609F6FC.4040609@sun.com> <460A2497.2060604@sun.com>
 <460A7EDD.3030504@Sun.COM> <460AC5C9.8090500@sun.com>
 <460CE161.6080006@sun.com> <460DAFCF.3090509@sun.com>
User-Agent: Thunderbird 2.0b2 (X11/20070227)
Status: RO
Content-Length: 467

Joseph Kowalski wrote:

> Of course, the flaw here is many of our customer do upgrade, but skip 
> releases (old data: circa 5.5-5.8), so this doesn't work for them.
> 
> That said, I'm comfortable with the approach.  We gave them a viable path.

Yes, it's not perfect but it is in line with our general EOF policy - 
you get a full release between the EOF being declared and the feature 
being removed - and we do publish EOF notices for perl.

-- 
Alan Burlison
--

From Stefan.Teleman@sun.com Mon Apr  2 10:58:24 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l32HwNIT023734
	for ; Mon, 2 Apr 2007 10:58:24 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l32Hvmo3021975;
	Tue, 3 Apr 2007 01:57:52 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFV00B05TWDP800@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 02 Apr 2007 10:57:49 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.106.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFV00HFNTWD6290@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 02 Apr 2007 10:57:49 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l32Hvmik987318; Mon,
 02 Apr 2007 10:57:48 -0700 (PDT)
Date: Mon, 02 Apr 2007 13:57:47 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460C66C8.602@Sun.COM>
To: PSARC-EXT@sun.com
Cc: Bart Smaalders , Joseph Kowalski ,
        David Comay 
Reply-to: Stefan Teleman 
Message-id: <4611441B.9000509@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 370

Bart Smaalders wrote:
> An updated copy of the fast track with corrections
> (case numbers, 64 bit paths, etc) has been placed in
> the materials subdirectory.

Hi.

I was just wondering if these FastTrack updates are ok, or maybe other 
corrections/updates were needed.

Thank you very much.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Tue Apr  3 14:21:40 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l33LLdAk029275
	for ; Tue, 3 Apr 2007 14:21:39 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l33LKntn003277;
	Tue, 3 Apr 2007 22:21:06 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFX0010XXZ5UN00@brm-avmta-1.central.sun.com>; Tue,
 03 Apr 2007 15:21:05 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFX00AK9XZ5M8B0@brm-avmta-1.central.sun.com>; Tue,
 03 Apr 2007 15:21:05 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l33LKwHs280425;
 Tue, 03 Apr 2007 14:21:03 -0700 (PDT)
Date: Tue, 03 Apr 2007 11:20:26 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4611441B.9000509@Sun.COM>
To: Stefan Teleman 
Cc: PSARC-EXT@sun.com, Bart Smaalders ,
        David Comay 
Message-id: <4612C51A.50506@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1163

Stefan Teleman wrote:
> Bart Smaalders wrote:
>> An updated copy of the fast track with corrections
>> (case numbers, 64 bit paths, etc) has been placed in
>> the materials subdirectory.
>
> Hi.
>
> I was just wondering if these FastTrack updates are ok, or maybe other 
> corrections/updates were needed.
>
> Thank you very much.
>
> --Stefan
What is the point of the header file list in the exported interfaces 
table?  Are these the documentation for
the list of extensions which follows?  I guess for something Uncommitted 
and versioned as proposed, I
can live with using the headers as the documentation, but this needs to 
be a lot clearer.  (also, the headers
need to be captured).

Most importantly, where is the paragraph or two (or three) describing 
the Policy for adding and/or deleting
[versions] from our product?  Is this your's or David's to supply?

- jek3

Nit: you are inconsistent about using the old or new (or both) taxonomy 
in the imported interfaces table.
(If this is "what ever the referenced case used", I'd be fine, but I 
have trouble fitting the "both" into it.)
(This is a real nit. I can understand if you don't bother with it.)

From Stefan.Teleman@sun.com Tue Apr  3 18:06:36 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3416Zi6006822
	for ; Tue, 3 Apr 2007 18:06:35 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3415sL9017403;
	Wed, 4 Apr 2007 09:06:01 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFY002018E0PU00@nwk-avmta-2.sfbay.sun.com>; Tue,
 03 Apr 2007 18:06:00 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.58.37])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFY00L378DZ6L50@nwk-avmta-2.sfbay.sun.com>; Tue,
 03 Apr 2007 18:06:00 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3415wup264240; Tue,
 03 Apr 2007 18:05:59 -0700 (PDT)
Date: Tue, 03 Apr 2007 21:05:54 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4612C51A.50506@sun.com>
To: Joseph Kowalski 
Cc: PSARC-EXT@sun.com, Bart Smaalders ,
        David Comay 
Reply-to: Stefan Teleman 
Message-id: <4612F9F2.9070704@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 2405

Joseph Kowalski wrote:

> What is the point of the header file list in the exported interfaces 
> table?  Are these the documentation for
> the list of extensions which follows?  I guess for something Uncommitted 
> and versioned as proposed, I
> can live with using the headers as the documentation, but this needs to 
> be a lot clearer.  (also, the headers
> need to be captured).

The purpose of the header files included in the FastTrack is to give a general 
sense for the *location* of PHP5's Interfaces. The complete documentation set 
for the PHP Interfaces is extremely large. It is available in HTML format, and 
the full documentation set in HTML will be included in the SUNWphp520doc package 
(which is different from, and orders of magnitude larger than, SUNWphp520man, 
which only includes man pages).
> 
> Most importantly, where is the paragraph or two (or three) describing 
> the Policy for adding and/or deleting
> [versions] from our product?  Is this your's or David's to supply?

The Upgrade/Delete Policy for PHP5 will follow the Perl one:

- a new version of PHP5 will be introduced if/when it provides a
set of new functionality that is desired to make available to the
community, or by explicit community request
- Within Nevada builds (expressily and explicitly excluding "FCS" and/or Update 
releases), PHP5 may be upgraded from one Nevada release to another. This will be 
determined primarily by bug/security fixes.
- Once a PHP5 version has shipped in either a FCS or Update Release, it will not 
be removed for the lifetime of that particular Release. It may, however, be 
updated/patched, or it may introduce new functionality or facilities, observing 
backwards compatibility
- A *new* version of PHP may not necessarily maintain compatibility with 
previous versions of PHP. However, in the current proposal, incompatible 
versions of PHP will reside in their own directory tree.

> Nit: you are inconsistent about using the old or new (or both) taxonomy 
> in the imported interfaces table.
> (If this is "what ever the referenced case used", I'd be fine, but I 
> have trouble fitting the "both" into it.)

Oh, this is because i observed the Taxonomy advertised by each particular 
interface (for example, OpenSSL advertises itself as External/Volatile, whereas 
tcp-wrappers is Evolving).

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Tue Apr  3 18:56:01 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l341u023007767
	for ; Tue, 3 Apr 2007 18:56:00 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l341tFT0000520;
	Wed, 4 Apr 2007 09:55:26 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFY00501AOC6Y00@nwk-avmta-2.sfbay.sun.com>; Tue,
 03 Apr 2007 18:55:24 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFY00LXPAOC6H70@nwk-avmta-2.sfbay.sun.com>; Tue,
 03 Apr 2007 18:55:24 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l341tNFu318516;
 Tue, 03 Apr 2007 18:55:23 -0700 (PDT)
Date: Tue, 03 Apr 2007 15:54:55 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4612F9F2.9070704@Sun.COM>
To: Stefan Teleman 
Cc: PSARC-EXT@sun.com, Bart Smaalders ,
        David Comay 
Message-id: <4613056F.1050808@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 2430

Stefan Teleman wrote:
> Joseph Kowalski wrote:
>
>> What is the point of the header file list in the exported interfaces 
>> table?  Are these the documentation for
>> the list of extensions which follows?  I guess for something 
>> Uncommitted and versioned as proposed, I
>> can live with using the headers as the documentation, but this needs 
>> to be a lot clearer.  (also, the headers
>> need to be captured).
>
> The purpose of the header files included in the FastTrack is to give a 
> general sense for the *location* of PHP5's Interfaces. The complete 
> documentation set for the PHP Interfaces is extremely large. It is 
> available in HTML format, and the full documentation set in HTML will 
> be included in the SUNWphp520doc package (which is different from, and 
> orders of magnitude larger than, SUNWphp520man, which only includes 
> man pages). Most importantly, where is the paragraph or two (or three) 
> describing the Policy for adding and/or deleting
>> [versions] from our product?  Is this your's or David's to supply?
>
> The Upgrade/Delete Policy for PHP5 will follow the Perl one:
>
> - a new version of PHP5 will be introduced if/when it provides a
> set of new functionality that is desired to make available to the
> community, or by explicit community request
> - Within Nevada builds (expressily and explicitly excluding "FCS" 
> and/or Update releases), PHP5 may be upgraded from one Nevada release 
> to another. This will be determined primarily by bug/security fixes.
> - Once a PHP5 version has shipped in either a FCS or Update Release, 
> it will not be removed for the lifetime of that particular Release. It 
> may, however, be updated/patched, or it may introduce new 
> functionality or facilities, observing backwards compatibility
> - A *new* version of PHP may not necessarily maintain compatibility 
> with previous versions of PHP. However, in the current proposal, 
> incompatible versions of PHP will reside in their own directory tree.
>
>> Nit: you are inconsistent about using the old or new (or both) 
>> taxonomy in the imported interfaces table.
>> (If this is "what ever the referenced case used", I'd be fine, but I 
>> have trouble fitting the "both" into it.)
>
> Oh, this is because i observed the Taxonomy advertised by each 
> particular interface (for example, OpenSSL advertises itself as 
> External/Volatile, whereas tcp-wrappers is Evolving).
>
> --Stefan
>


From jek3@sun.com Tue Apr  3 19:09:41 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3429fws007803
	for ; Tue, 3 Apr 2007 19:09:41 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l34296Bk014237;
	Wed, 4 Apr 2007 03:09:07 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFY00805BB5MV00@brm-avmta-1.central.sun.com>; Tue,
 03 Apr 2007 20:09:05 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFY003M3BB0T720@brm-avmta-1.central.sun.com>; Tue,
 03 Apr 2007 20:09:05 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3428t7P319972;
 Tue, 03 Apr 2007 19:08:55 -0700 (PDT)
Date: Tue, 03 Apr 2007 16:08:27 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4612F9F2.9070704@Sun.COM>
To: Stefan Teleman 
Cc: PSARC-EXT@sun.com, Bart Smaalders ,
        David Comay 
Message-id: <4613089B.1010102@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 3550

Stefan Teleman wrote:
> Joseph Kowalski wrote:
>
>> What is the point of the header file list in the exported interfaces 
>> table?  Are these the documentation for
>> the list of extensions which follows?  I guess for something 
>> Uncommitted and versioned as proposed, I
>> can live with using the headers as the documentation, but this needs 
>> to be a lot clearer.  (also, the headers
>> need to be captured).
>
> The purpose of the header files included in the FastTrack is to give a 
> general sense for the *location* of PHP5's Interfaces. The complete 
> documentation set for the PHP Interfaces is extremely large. It is 
> available in HTML format, and the full documentation set in HTML will 
> be included in the SUNWphp520doc package (which is different from, and 
> orders of magnitude larger than, SUNWphp520man, which only includes 
> man pages).
OK.  Please move them out of the middle of the interface table in the 
spec and place a paragraph similar to the above in the spec to explain 
why they are there.
>>
>> Most importantly, where is the paragraph or two (or three) describing 
>> the Policy for adding and/or deleting
>> [versions] from our product?  Is this your's or David's to supply?
In the spec please. I want very specific words to review and (hopefully) 
approve.
=============
> The Upgrade/Delete Policy for PHP5 will follow the Perl one:
>
> - a new version of PHP5 will be introduced if/when it provides a
> set of new functionality that is desired to make available to the
> community, or by explicit community request
> - Within Nevada builds (expressily and explicitly excluding "FCS" 
> and/or Update releases), PHP5 may be upgraded from one Nevada release 
> to another. This will be determined primarily by bug/security fixes.
I can't parse this.

Its a loophole that we are productizing Nevada-Express and not being 
force to hold interfaces constant.  We gotta do something about that.

Once you integrate into Nevada, think of it as having shipped.
> - Once a PHP5 version has shipped in either a FCS or Update Release, 
> it will not be removed for the lifetime of that particular Release. It 
> may, however, be updated/patched, or it may introduce new 
> functionality or facilities, observing backwards compatibility
I guess I guessed right above.

I'd like the ARC to consider what's right here.  "right" may take a 
tweak (either general or specific) to the rules.
> - A *new* version of PHP may not necessarily maintain compatibility 
> with previous versions of PHP. However, in the current proposal, 
> incompatible versions of PHP will reside in their own directory tree.
It should also mention that ARC review (hopefully fast-track) will be 
required for adding or removing any version.  I think David said or 
agreed to
this.  (Humm, maybe being explicit about this deals with my above concern).

It may already do this (if so, I missed it), but the spec needs to say 
*exactly* which version.  Should you decide to change your mind about 
this, it should be a trivially easy change to get made.

I guess we dropped all the links?  Just checking.
>
>> Nit: you are inconsistent about using the old or new (or both) 
>> taxonomy in the imported interfaces table.
>> (If this is "what ever the referenced case used", I'd be fine, but I 
>> have trouble fitting the "both" into it.)
>
> Oh, this is because i observed the Taxonomy advertised by each 
> particular interface (for example, OpenSSL advertises itself as 
> External/Volatile, whereas tcp-wrappers is Evolving).
OK, cool.

- jek3


From jek3@sun.com Tue Apr  3 19:18:14 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l342IEEL007965
	for ; Tue, 3 Apr 2007 19:18:14 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l342HgeU038781;
	Tue, 3 Apr 2007 20:17:42 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFY00601BPIH600@nwk-avmta-2.sfbay.sun.com>; Tue,
 03 Apr 2007 19:17:42 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFY00L2DBPH6H90@nwk-avmta-2.sfbay.sun.com>; Tue,
 03 Apr 2007 19:17:41 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l342HedI321505;
 Tue, 03 Apr 2007 19:17:40 -0700 (PDT)
Date: Tue, 03 Apr 2007 16:17:12 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4613056F.1050808@sun.com>
To: Joseph Kowalski 
Cc: Stefan Teleman , PSARC-EXT@sun.com,
        Bart Smaalders ,
        David Comay 
Message-id: <46130AA8.7070504@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613056F.1050808@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 2674


Cute.  Thunderbird said I was fast enough to cancel this mis-send, but 
it lied.

Move on to the next messsage. Nothing to see here folks.  More along, 
move along,...

Joseph Kowalski wrote:
> Stefan Teleman wrote:
>> Joseph Kowalski wrote:
>>
>>> What is the point of the header file list in the exported interfaces 
>>> table?  Are these the documentation for
>>> the list of extensions which follows?  I guess for something 
>>> Uncommitted and versioned as proposed, I
>>> can live with using the headers as the documentation, but this needs 
>>> to be a lot clearer.  (also, the headers
>>> need to be captured).
>>
>> The purpose of the header files included in the FastTrack is to give 
>> a general sense for the *location* of PHP5's Interfaces. The complete 
>> documentation set for the PHP Interfaces is extremely large. It is 
>> available in HTML format, and the full documentation set in HTML will 
>> be included in the SUNWphp520doc package (which is different from, 
>> and orders of magnitude larger than, SUNWphp520man, which only 
>> includes man pages). Most importantly, where is the paragraph or two 
>> (or three) describing the Policy for adding and/or deleting
>>> [versions] from our product?  Is this your's or David's to supply?
>>
>> The Upgrade/Delete Policy for PHP5 will follow the Perl one:
>>
>> - a new version of PHP5 will be introduced if/when it provides a
>> set of new functionality that is desired to make available to the
>> community, or by explicit community request
>> - Within Nevada builds (expressily and explicitly excluding "FCS" 
>> and/or Update releases), PHP5 may be upgraded from one Nevada release 
>> to another. This will be determined primarily by bug/security fixes.
>> - Once a PHP5 version has shipped in either a FCS or Update Release, 
>> it will not be removed for the lifetime of that particular Release. 
>> It may, however, be updated/patched, or it may introduce new 
>> functionality or facilities, observing backwards compatibility
>> - A *new* version of PHP may not necessarily maintain compatibility 
>> with previous versions of PHP. However, in the current proposal, 
>> incompatible versions of PHP will reside in their own directory tree.
>>
>>> Nit: you are inconsistent about using the old or new (or both) 
>>> taxonomy in the imported interfaces table.
>>> (If this is "what ever the referenced case used", I'd be fine, but I 
>>> have trouble fitting the "both" into it.)
>>
>> Oh, this is because i observed the Taxonomy advertised by each 
>> particular interface (for example, OpenSSL advertises itself as 
>> External/Volatile, whereas tcp-wrappers is Evolving).
>>
>> --Stefan
>>
>


From sommerfeld@sun.com Tue Apr  3 19:20:53 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l342KrN8007979
	for ; Tue, 3 Apr 2007 19:20:53 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l342KL1f038994;
	Tue, 3 Apr 2007 20:20:21 -0600 (MDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFY0090DBTXT200@brm-avmta-1.central.sun.com>; Tue,
 03 Apr 2007 20:20:21 -0600 (MDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFY0032WBTWT730@brm-avmta-1.central.sun.com>; Tue,
 03 Apr 2007 20:20:20 -0600 (MDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l342KJWU005397; Tue, 03 Apr 2007 22:20:19 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l342KJel007774; Tue,
 03 Apr 2007 22:20:19 -0400 (EDT)
Date: Tue, 03 Apr 2007 22:20:17 -0400
From: Bill Sommerfeld 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4613089B.1010102@sun.com>
To: Joseph Kowalski 
Cc: Stefan Teleman , PSARC-EXT@sun.com
Message-id: <1175653217.1001.241.camel@thunk>
MIME-version: 1.0
X-Mailer: Evolution 2.8.1.1
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
Status: RO
Content-Length: 573

On Tue, 2007-04-03 at 16:08 -1000, Joseph Kowalski wrote:
> Once you integrate into Nevada, think of it as having shipped.

so, I agree that the current model is being unreasonably stretched, but
this strikes me as an overreaction, especially if by "integrate" you
mean "putback", but even if you really mean "escape into the wild in an
official numbered biweekly build"; I'd think that as a minimum it's
appropriate to have a grace period of a build or three to permit
incompatible changes to correct horrible mistakes that weren't
immediately noticed.

							- Bill





From jek3@sun.com Tue Apr  3 19:28:18 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l342SHhn008012
	for ; Tue, 3 Apr 2007 19:28:18 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l342Rf1h007945;
	Wed, 4 Apr 2007 10:27:43 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFY00601C66JA00@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 03 Apr 2007 19:27:42 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFY004NXC659NB0@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 03 Apr 2007 19:27:41 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l342RfLo323096;
 Tue, 03 Apr 2007 19:27:41 -0700 (PDT)
Date: Tue, 03 Apr 2007 16:27:13 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <1175653217.1001.241.camel@thunk>
To: Bill Sommerfeld 
Cc: Stefan Teleman , PSARC-EXT@sun.com
Message-id: <46130D01.1020909@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1262

Bill Sommerfeld wrote:
> On Tue, 2007-04-03 at 16:08 -1000, Joseph Kowalski wrote:
>   
>> Once you integrate into Nevada, think of it as having shipped.
>>     
>
> so, I agree that the current model is being unreasonably stretched, but
> this strikes me as an overreaction, especially if by "integrate" you
> mean "putback", but even if you really mean "escape into the wild in an
> official numbered biweekly build"; I'd think that as a minimum it's
> appropriate to have a grace period of a build or three to permit
> incompatible changes to correct horrible mistakes that weren't
> immediately noticed.
>
> 							- Bill
>   
Well, first I did mean "escaped into the wild".

Counting builds and such is too much work.

Actually, I think our current processes still work.  Since I'm requiring 
a version
be specified as part of this project, such a change will require a 
revisit to the ARC.
(That in itself might help deter unnecessary change.)  In the past, the 
requests which
began "I'd like to change my spec, but it hasn't yet shipped..." caused 
the ARC to
allow any change (for the good) with out considering the previous 
integration.
We will now just start needing to pay a little more attention to how 
long ago it
escaped into the wild.

- jek3


From Stefan.Teleman@sun.com Wed Apr  4 09:28:53 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34GSqCB020969
	for ; Wed, 4 Apr 2007 09:28:53 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l34GS99T004220;
	Thu, 5 Apr 2007 00:28:16 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFZ00159F33Z800@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 04 Apr 2007 09:28:15 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.106.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFZ00LO4F2ZEN50@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 04 Apr 2007 09:28:12 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34GRn4v314128; Wed,
 04 Apr 2007 09:27:54 -0700 (PDT)
Date: Wed, 04 Apr 2007 12:27:46 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46130D01.1020909@sun.com>
To: Joseph Kowalski 
Cc: Bill Sommerfeld , PSARC-EXT@sun.com,
        Bart Smaalders , David Comay ,
        Fred Thornborrow 
Reply-to: Stefan Teleman 
Message-id: <4613D202.7070300@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_aJva/v7hs2BVWb461J1NLw)"
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 15362

This is a multi-part message in MIME format.

--Boundary_(ID_aJva/v7hs2BVWb461J1NLw)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

Joseph Kowalski wrote:

> Actually, I think our current processes still work.  Since I'm requiring 
> a version
> be specified as part of this project, such a change will require a 
> revisit to the ARC.

Revised version of PHP5 Fast Track attached.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


--Boundary_(ID_aJva/v7hs2BVWb461J1NLw)
Content-type: text/plain; name=PHP5FastTrack.asc
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=PHP5FastTrack.asc

Including PHP5 with Solaris

Stefan Teleman 
15 March 2007

1.	Summary and motivation

	The inclusion of PHP5 in Solaris as a component of SAPP
	[Solaris, Apache, PostgreSQL, PHP] will address a current
	shortcoming of SMI's software portfolio.
	
	The absence in Solaris of a LAMP [Linux, Apache, MySQL, PHP]
	equivalent software stack has allowed Linux to create the
	perception that it is the operating environment of choice for
	web-based applications.

	This case seeks Micro/Patch Release Binding.
		
2.	Technical issues

	2.1.	Key objects.
		
	/usr/php5/[version]/bin/php
	/usr/php5/[version]/bin/php-config
	/usr/php5/[version]/bin/phpize

	/usr/php5/[version]/bin/64/php
	/usr/php5/[version]/bin/64/php-config
	/usr/php5/[version]/bin/64/phpize


	/usr/php5/[version]/lib/libphp5-5.2.0.so
	/usr/php5/[version]/lib/libphp5.so -> /usr/php5/[version]/lib/libphp5-5.2.0.so
	/usr/php5/[version]/lib/64/libphp5-5.2.0.so
	/usr/php5/[version]/lib/64/libphp5.so -> /usr/php5/[version]/lib/64/libphp5-5.2.0.so

	/usr/php5/[version]/etc/php.ini

	All other objects will be contained within the /usr/php5/[version]
	hierarchy.  This hierarchy will loosely track that of the publicly
	available version.
	
	The current version of PHP5 [5.2.0] is 64-bit clean and largefile
	aware. A 64-bit version of PHP is being considered for a future
	release.
	
	2.2.	Versioning
	
	The PHP5 development process follows the ubiquitous
	"continuous development" model, typical of many Open Source projects.
	Currently, two Releases of PHP coexist, and are still under
	development: PHP4 and PHP5. Also, PHP6 is currently under active
	development, and is scheduled to be released sometime during 2007.
	None of these three Releases make any guarantees of API and ABI
	compatibility.
		
	The PHP versioning model has followed the ..
	model. The version of PHP5 proposed for inclusion in Solaris is PHP
	5.2.0.
	
	2.3.	Directory Naming and Structure
	
	The proposed directory layout for PHP5 is:
		/usr/php5/
			[version]/bin
			[version]/bin/64
			[version]/doc
			[version]/etc	
			[version]/include
			[version]/lib
			[version]/lib/64
			[version]/man
			[version]/modules/64
			[version]/share

	The detailed directory and file layout for PHP5 is provided in
	Addendum 1.

	2.4.	Packaging and Delivery

	The current proposal allows for the inclusion and coexistence
	of multiple versions of PHP by keeping each installation under
	a version-specific subdirectory. The following package naming
	convention is proposed:

		SUNWphp520root
		SUNWphp520core
		SUNWphp520usr
		SUNWphp520man
		SUNWphp520doc

	SUNWphp520root will deliver only one file, the system-wide PHP5
	configuration file for each particular PHP release:

		/etc/php5/[version]/php.ini

	SUNWphp520core will deliver the minimal filesystem objects for a
	functional PHP5 Apache installation:

		SUNWphp520core:

		/usr/php5/[version]/lib
		/usr/php5/[version]/lib/64
		/usr/php5/[version]/modules
		/usr/php5/[version]/modules/64

	SUNWphp520usr will deliver the additional userland and developer
	filesystem objects:

		SUNWphp520usr:

		/usr/php5/[version]/bin
		/usr/php5/[version]/bin/64
		/usr/php5/[version]/include
		/usr/php5/[version]/share

	SUNWphp520doc will deliver the full and complete PHP5
	documentation in HTML format.

	SUNWphp520man will deliver the available man pages for PHP5:

		/usr/share/man/man1/php.1
		/usr/php5/[version]/man/man1/php.1
		/usr/php5/[version]/man/man1/php-config.1
		/usr/php5/[version]/man/man1/phpize.1

3.	PHP5 Modules [Extensions].

	PHP supports a loadable module interface (known in PHP parlance
	as "Extensions"), allowing the PHP runtime to communicate with,
	and bind to, external interfaces. This module interface also allows
	for the clean integration of new PHP features or bindings. In addition,
	SMI may want to provide customers internally developed PHP Extensions.
	PHP Extensions have an associated dynamically loadable shared object
	(*.so). As mentioned earlier, PHP makes no guarantee of binary
	compatibility between releases. Maintaining PHP within the constraint
	of such possible binary incompatibilities motivates the directory
	layout structure proposed in 2.3.
		
	3.1.	PHP Core Modules.
	
	The initial integration will provide a subset of the PHP5
	Core Extensions as delivered by the canonical PHP5 Release:

		pcre [Perl-Compatible Regular Expressions]
		idn [International Domain Names Resolver]
		gd [Graphics Device]
		exif [EXIF Metadata Information]
		psql [PostgreSQL bindings]
		mbstring [Multi-Byte Strings/UTF Encoding bindings]
		gettext [GNU-compatible gettext binding]
		iconv [GNU compatible character encoding/conversion bindings]
		xml [XML bindings]
		pdo [PHP Database Objects bindings]
		pgsql [PostgreSQL bindings]
		soap [SOAP bindings]
		spl [Standard PHP Library]
		ssl [OpenSSL bindings]
		tcpwrap [TCPWrap bindings]
		tidy [HTML parsing and validation library]
		zlib [libz compression bindings]
		bz2 [libbz2 compression bindings]
		zip [libzip bindings]
		json [JavaScript bindings]
		bcmath [Binary Calculator Math bindings]
		calendar [Calendar bindings]
		ctype [Character bindings]
		curl [C-URL bindings]
		dom [DOM XSLT bindings]
		posix [POSIX bindings]
		sockets [libsocket bindings]
		session [PHP Session bindings]
		suhosin [Hardened PHP Extension]
		apc [Advanced PHP Caching Extension]

	Additional Extensions can be delivered subsequent to the initial
	PHP5 integration, depending on customer requests, and on the
	availability of the external dependencies required by these Extensions.

4.	PHP5 Internationalization.

	PHP5 provide basic I18N support via its ctype/gettext/iconv/mbstring
	Extensions. As an externally developed application, PHP5 will not
	provide additional Internationalization support beyond what is provided
	by the canonical distribution.

5.	PHP5 Documentation.

	PHP5 comes with an exhaustive set of documentation available in several
	languages from the PHP Site [http://www.php.net/docs.php] [2].

	5.1.	Full Adoption.

	The full PHP5 documentation is available for download from the PHP Site
	[http://www.php.net/download-docs.php] [3]. This documentation collection
	should be placed in the separate [doc] directory for each PHP5 Release
	[/usr/php5/[version]/doc].

	5.2.	Manual Pages.

	PHP5 provides a default man page [php(1)]. This man page will be
	delivered in the appropriate man directory [/usr/php5/[version]/man],
	with an appropriate symbolic link to /usr/php5/man. The contents of
	this man page is provided in Addendum 2.

	A generic man page will be delivered in the standard Solaris man
	directory (/usr/share/man/man1/php.1). This man page will follow
	the model introduced by Perl5 [PSARC 1999/192], and will provide
	a complete listing of available PHP5 man pages [php(1), phpize(1)
	and php-config(1)]. The contents of this man page is provided in
	Addendum 3.

6.	Interfaces

	6.1.	Interface Stability.

	PHP, as an Open Source project, is controlled by a group of developers
	external of, and independent from, SMI. The PHP Group makes no
	guarantees or promises of ABI or API compatibility between PHP releases.

	6.2.	Imported Interfaces.

	NAME				STABILITY		NOTES

	Apache 2.2 APR Libraries	Uncommitted		PSARC/2007/169
	OpenSSL	[Secure Sockets Layer]	External/Volatile	PSARC/2003/500
	PCRE [Perl-Compatible Regular Expressions] Uncommitted	PSARC/2007/164
	IDN [Internationalized Domain Library]	Uncommitted	PSARC/2007/167
	GD [Graphics Device Library]	Uncommitted		PSARC/2007/166
	EXIF [EXIF Metadata Information]	Uncommitted	LSARC/2006/202
	PostgreSQL			Uncommitted		LSARC/2006/655
	TCPWrap [TCP Wrappers Library]	Evolving		PSARC/2001/709
	Tidy [HTML Validation Library]	Uncommitted		PSARC/2007/134
	Z-lib [Zlib Compression Library]	Committed	PSARC/2006/537
	BZ2 [bz2 Compression Library]	Standard		PSARC/1999/555
	ZIP [Zip Compression Library]	Standard		PSARC/1999/555
	CURL [C-URL Library]		Uncommitted		PSARC/2007/165
	LibXML [XML Library]		Standard		PSARC/2001/175
	LibXSLT [XSLT Transformation Library]	Evolving	PSARC/2002/244
	LibFreetype 2 [Freetype Library]	External	LSARC/2005/397
	LibFontconfig [Fontconfig Library]	External	LSARC/2003/273

	6.3.	Exported Interfaces.

	PHP5 implements two types of Exported Interfaces. The first type
	[Type 1] is a one-to-one mappping between a physical filesystem
	object, and its associated Interfaces. The second type [Type 2] is
	a virtual mapping of two distinct Interface Objects: a physical
	filesystem object and an Interface moniker handle which may, or
	may not act as a provider of programmatic interface(s). Not all
	Type 2 Interfaces provide a programmatic interface. Typically,
	but not always, Type 2 Interfaces which do not provide a programmatic
	interface, provide a configuration interface via the php.ini file.

	This Type 2 Interface is characteristic of PHP5's Extensions.
	Also characteristic of the Type 2 Interface is the property
	that physical filesystem object Interfaces are always Private and
	implicitly Volatile, whereas their corresponding programmatic, or
	configuration interfaces, if they exist, are public and Uncommitted.

	NAME			STABILITY		NOTES

	SUNWphp520core		Uncommitted		Package Name
	SUNWphp520usr		Uncommitted		Package Name
	SUNWphp520man		Uncommitted		Package Name
	SUNWphp520doc		Uncommitted		Package Name

	/usr/php5/[version]/bin/php	Uncommitted	Executable location
	/usr/php5/[version]/bin/64/php	Uncommitted	Executable location

	/usr/php5/[version]/bin/phpize	Uncommitted	Executable location
	/usr/php5/[version]/bin/64/phpize	Uncommitted	Executable location

	/usr/php5/[version]/bin/php-config	Uncommmited	Executable location
	/usr/php5/[version]/bin/64/php-config	Uncommmited	Executable location

	/etc/php5/[version]/php.ini	Uncommitted	Configuration file

	/usr/php5/[version]/lib/libphp5-[version].so	Uncommitted	PHP Library
	/usr/php5/[version]/lib/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic link
	/usr/php5/[version]/lib/64/libphp5-[version].so Uncommitted	PHP Library
	/usr/php5/[version]/lib/64/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic Link

	apc	Uncommitted	APC Extension
	bcmath	Uncommitted	BC Math Extension
	bz2	Uncommitted	BZ2 Extension
	calendar Uncommitted	Calendar Extension
	ctype	Uncommitted	Character Extension
	curl	Uncommitted	C-URL Extension
	dba	Uncommitted	Database Access Extension
	dom	Uncommitted	XML DOM Extension
	dtrace	Uncommitted	DTrace Extension
	exif	Uncommitted	EXIF Extension
	filter	Uncommitted	Filter Extension
	ftp	Uncommitted	FTP Extension
	gd	Uncommitted	GD Extension
	gettext	Uncommitted	Gettext Extension
	hash	Uncommitted	PHP Hashing Extension
	iconv	Uncommitted	GNU Iconv Compatible Extension
	json	Uncommitted	JavaScript Object Notation Extension
	libxml	Uncommitted	LibXML Extension
	mbstring	Uncommitted	Multi-byte Strings Extension
	openssl	Uncommitted	OpenSSL Extension
	pcntl	Uncommitted	Process Control Extension
	pcre	Uncommitted	PCRE Extension
	pdo	Uncommitted	PHP Database Objects Extension
	pdo_pgsql	Uncommitted	PostgreSQL PHP Database Objects Extension
	pgsql	Uncommitted	PHP PostgreSQL Native Extension
	posix	Uncommitted	PHP POSIX Emulation Extension
	session	Uncommitted	PHP Session Management Extension
	shmop	Uncommitted	PHP Shared Memory Extension
	simplexml	Uncommitted	PHP XML Extension
	soap	Uncommitted	PHP SOAP Extension
	sockets	Uncommitted	PHP Sockets Extension
	spl	Uncommitted	Standard PHP Library Extension
	suhosin	Uncommitted	Hardened PHP Security Extension
	sysvmsg	Uncommitted	SVR4 IPC Extension
	sysvsem	Uncommitted	SVR4 Semaphores Extension
	sysvshm	Uncommitted	SVR4 Shared memory Extension
	tcpwrap	Uncommitted	TCP Wrapper Library Extension
	tidy	Uncommitted	TIDY Library Extension
	tokenizer	Uncommitted	PHP Tokenizer Parser Extension
	xml	Uncommitted	LibXML Extension
	xlmreader	Uncommitted	LibXML Reader Extension
	xmlrpc	Uncommitted	LibXML RPC Extension
	xmlwriter	Uncommitted	LibXML Writer Extension
	xsl	Uncommitted	LibXSLT Extension
	zip	Uncommitted	ZIP Compression Extension
	zlib	Uncommitted	ZLib Compression Extension

	6.4.	Maintaining Interface Compatibility

	PHP5 does not make any guarantees of Interface Stability between
	minor or major releases. To wit, interface compatibility between
	PHP 5.1.6 and PHP 5.2.0 has been broken. In order to reconcile
	this inherent interface instability with Solaris' interface
	stability constraints, we propose the following set of assumptions
	and rules governing existing PHP updates and new PHP releases :

		6.4.1.	Assumptions

		No API or ABI Compatibility is implied, or is to be assumed,
		or inferred, between Major, Minor, or Micro PHP Releases.

		6.4.2.	Consequences And Ensuing Constraints

		0.	A new version of PHP will be introduced in Solaris if
		and when it provides a significant set of new functionality,
		or facilities, and when such facilities are of interest to,
		or have been expressly requested by, the Community.

		1.	Within "Nevada" [or subsequent development] Solaris
		builds, and explicitly excluding "FCS" and/or "Update"
		Releases, PHP may be upgraded, from one release to another.
		Sufficient notice for such upcoming upgrades will be provided,
		detailing any expected API or ABI compatibility breakage.

		2.	Once a PHP version has shipped, either in a "FCS" or
		an "Update" Solaris release, it will not be removed, for the
		lifetime of this particular Release. It may, however, be
		updated or patched, and it may introduce new functionality
		and/or facilities, provided that the Interface Stability
		Constraints controlling this PHP version are respected. An
		exception to this Constraint is explicitly granted to security
		patches or upgrades.

		3.	A new version of PHP may be introduced in a patch, or
		in a "FCS" or "Upgrade" Solaris Release. It is mandated that
		Binary Incompatible Releases of PHP reside in their own,
		separate, directory trees, thereby observing the Interface
		Stability Constraints enforced by any previous [existing] PHP
		Releases.

7.	References.

	[1]	http://www.php.net/
	[2]	http://www.php.net/docs.php
	[3]	http://www.php.net/download-docs.php
	[4]	http://www.php.net/license/3_01.txt
	[5]	http://bugs.php.net/
	[6]	http://www.libgd.org/
	[7]	http://curl.haxx.se/
	[8]	http://www.pcre.org/
	[9]	http://tidy.sourceforge.net/
	[10]	http://sourceforge.net/project/showfiles.php?group_id=12272
	[11]	http://www.littlecms.com/
	[12]	http://www.gnu.org/software/libidn/
	[13]	http://www.hardened-php.net/
	[14]	http://www.postgresql.org/
	[15]	http://www.apache.org/
	[16]	http://www.xmlsoft.org/
	[17]	http://www.openssl.org/
	

--Boundary_(ID_aJva/v7hs2BVWb461J1NLw)--

From jek3@sun.com Wed Apr  4 11:47:35 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34IlZ7p028896
	for ; Wed, 4 Apr 2007 11:47:35 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l34Il1GB035035;
	Wed, 4 Apr 2007 12:47:02 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFZ00B3BLIDZT00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 04 Apr 2007 11:47:01 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFZ00AGVLIC2L40@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 04 Apr 2007 11:47:00 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l34IkxHQ443768;
 Wed, 04 Apr 2007 11:46:59 -0700 (PDT)
Date: Wed, 04 Apr 2007 08:46:30 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4613D202.7070300@Sun.COM>
To: Stefan Teleman 
Cc: Bill Sommerfeld , PSARC-EXT@sun.com,
        Bart Smaalders , David Comay ,
        Fred Thornborrow 
Message-id: <4613F286.6010506@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 3687


Getting close.  See comments below.

The specific version you are proposing to integrate needs to be 
specified (so our processes work).  Initially, this should be
easy to change, becoming more difficult as time goes on.

Stefan Teleman wrote:
> 	6.3.	Exported Interfaces.
>   
...
> 	/usr/php5/[version]/lib/libphp5-[version].so	Uncommitted	PHP Library
> 	/usr/php5/[version]/lib/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic link
> 	/usr/php5/[version]/lib/64/libphp5-[version].so Uncommitted	PHP Library
> 	/usr/php5/[version]/lib/64/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic Link
>   
Sorry, missed this before.  Does my same concern about [version] and 
SONAME apply here? (That's *not* the [version] in the PATH.)  If these 
are Uncommitted (as opposed to Private), I think they would.  Please 
update (and the other specs where this applies while you are at it).
> 	6.4.	Maintaining Interface Compatibility
>
> 	PHP5 does not make any guarantees of Interface Stability between
> 	minor or major releases. To wit, interface compatibility between
> 	PHP 5.1.6 and PHP 5.2.0 has been broken. In order to reconcile
> 	this inherent interface instability with Solaris' interface
> 	stability constraints, we propose the following set of assumptions
> 	and rules governing existing PHP updates and new PHP releases :
>
> 		6.4.1.	Assumptions
>
> 		No API or ABI Compatibility is implied, or is to be assumed,
> 		or inferred, between Major, Minor, or Micro PHP Releases.
>
> 		6.4.2.	Consequences And Ensuing Constraints
>
> 		0.	A new version of PHP will be introduced in Solaris if
> 		and when it provides a significant set of new functionality,
> 		or facilities, and when such facilities are of interest to,
> 		or have been expressly requested by, the Community.
>
> 		1.	Within "Nevada" [or subsequent development] Solaris
> 		builds, and explicitly excluding "FCS" and/or "Update"
> 		Releases, PHP may be upgraded, from one release to another.
> 		Sufficient notice for such upcoming upgrades will be provided,
> 		detailing any expected API or ABI compatibility breakage.
>   
I don't agree.  How about:

                               1.            Any upgrade of PHP from the 
version specified in this
                               document must be approved by the ARC 
process.  It is expected
                               that initially upgrades may be easy to 
justify, growing more difficult
                               as exposure through Solaris Express and 
other mechanisms increases.

There is no blank check here.
> 		2.	Once a PHP version has shipped, either in a "FCS" or
> 		an "Update" Solaris release, it will not be removed, for the
> 		lifetime of this particular Release. It may, however, be
> 		updated or patched, and it may introduce new functionality
> 		and/or facilities, provided that the Interface Stability
> 		Constraints controlling this PHP version are respected. An
> 		exception to this Constraint is explicitly granted to security
> 		patches or upgrades.
>   
Nit: the security exception is in the taxonomy.  Its a given, but it 
doesn't hurt to restate it.
> 		3.	A new version of PHP may be introduced in a patch, or
> 		in a "FCS" or "Upgrade" Solaris Release. It is mandated that
> 		Binary Incompatible Releases of PHP reside in their own,
> 		separate, directory trees, thereby observing the Interface
> 		Stability Constraints enforced by any previous [existing] PHP
> 		Releases.
>   
In all of the above, I'm assume we are talking about [version] and not 
the "5" in PHP5.
Could you add a sentence to make that explicit.

Please respond with an updated full spec.

Almost there.

- thanks,

- jek3


From peter.tribble@gmail.com Wed Apr  4 13:38:53 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34Kcqbg001818
	for ; Wed, 4 Apr 2007 13:38:53 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l34KcBMd011455
	for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 4 Apr 2007 21:38:19 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFZ00D01QNUFA00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com
 (ORCPT PSARC-EXT@sun.com); Wed, 04 Apr 2007 13:38:18 -0700 (PDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFZ00BXUQNT4L60@nwk-avmta-2.sfbay.sun.com> for
 PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed,
 04 Apr 2007 13:38:18 -0700 (PDT)
Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged))
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l34KOUat020249	for
 ; Wed, 04 Apr 2007 20:38:17 +0000 (GMT)
Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34])
 by relay3.sun.com with ESMTP for PSARC-EXT@sun.com; Wed,
 04 Apr 2007 20:38:13 +0000 (Z)
Received: from relay2.sun.com (relay2.sun.com [150.143.103.24])
 by mms02es.sun.com with ESMTP id BT-MMP-420877 for PSARC-EXT@sun.com; Wed,
 04 Apr 2007 20:38:13 +0000 (Z)
Received: from nz-out-0506.google.com ([64.233.162.238] [64.233.162.238])
 by relay2.sun.com with ESMTP for PSARC-EXT@sun.com; Wed,
 04 Apr 2007 20:38:13 +0000 (Z)
Received: by nz-out-0506.google.com with SMTP id m7so189155nzf for
 ; Wed, 04 Apr 2007 13:38:13 -0700 (PDT)
Received: by 10.65.84.6 with SMTP id m6mr2080495qbl.1175719093100; Wed,
 04 Apr 2007 13:38:13 -0700 (PDT)
Received: by 10.64.220.10 with HTTP; Wed, 04 Apr 2007 13:38:13 -0700 (PDT)
Date: Wed, 04 Apr 2007 21:38:13 +0100
From: Peter Tribble 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4613D202.7070300@Sun.COM>
To: Stefan Teleman 
Cc: PSARC-EXT@sun.com
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;        d=gmail.com; s=beta;
 h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
 b=B0bhccAQMnhDrxYFA2i1lBuyVKp/0/3ekHBCoYiLuWFA4UY5IX33rUA0fEvXs6miPgG2NwyvUyRzOpqABzGgIJPTdfxs1VMfTj9XcNtKqUR9tDptnFD6KfsBppTkVfnTrGakupVkZkEBaZJZ25D+y/MjR5sRFE8I72MBRt2dE80=
DomainKey-Signature: a=rsa-sha1; c=nofws;        d=gmail.com; s=beta;
 h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
 b=WM8/6KW4WEW+6cBancxThB7X4JSWUSjM4dOZobjEkuXjEuy2aiZbnPD4SGzZsLw2ZjNQqridP8/qfiydprpbr+FX9geZ9IGR/l2zxnJ2QspTbrbCKuzZW2eQM0iDfpvu6lnp7603HUzC4Fw6CuMy8+31lGZGLAYQ1Yj3pOjL1bg=
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM>
Status: RO
Content-Length: 551

On 4/4/07, Stefan Teleman  wrote:
..
>         The absence in Solaris of a LAMP [Linux, Apache, MySQL, PHP]
...
>         The initial integration will provide a subset of the PHP5
>         Core Extensions as delivered by the canonical PHP5 Release:

Notable by their absence are the mysql and mysqli extensions. Pretty well
every installation of php I've ever used has needed one or both, and I would
regard the mysql extensions as essential.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

From peter.tribble@gmail.com Wed Apr  4 13:59:34 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34KxYbN003098
	for ; Wed, 4 Apr 2007 13:59:34 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l34Kx1ST028299
	for <@sunmail1brm.central.sun.com:psarc-ext@sun.com>; Wed, 4 Apr 2007 13:59:01 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFZ0020DRMDT900@brm-avmta-1.central.sun.com> for psarc-ext@sun.com
 (ORCPT psarc-ext@sun.com); Wed, 04 Apr 2007 14:59:01 -0600 (MDT)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFZ0059LRMCF6E0@brm-avmta-1.central.sun.com> for
 psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed,
 04 Apr 2007 14:59:00 -0600 (MDT)
Received: from relay41i.sun.com ([192.5.209.70])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l34Kx0CK013920	for
 ; Wed, 04 Apr 2007 20:59:00 +0000 (GMT)
Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231])
 by relay41i.sun.com with ESMTP for psarc-ext@sun.com; Wed,
 04 Apr 2007 20:59:00 +0000 (Z)
Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72])
 by mms48es.sun.com with ESMTP for psarc-ext@sun.com; Wed,
 04 Apr 2007 20:59:00 +0000 (Z)
Received: from nz-out-0506.google.com ([64.233.162.228] [64.233.162.228])
 by relay4i.sun.com with ESMTP for psarc-ext@sun.com; Wed,
 04 Apr 2007 20:59:00 +0000 (Z)
Received: by nz-out-0506.google.com with SMTP id m7so192390nzf for
 ; Wed, 04 Apr 2007 13:58:59 -0700 (PDT)
Received: by 10.65.74.9 with SMTP id b9mr2095932qbl.1175720339683; Wed,
 04 Apr 2007 13:58:59 -0700 (PDT)
Received: by 10.64.220.10 with HTTP; Wed, 04 Apr 2007 13:58:59 -0700 (PDT)
Date: Wed, 04 Apr 2007 21:58:59 +0100
From: Peter Tribble 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <460BE312.1080203@Sun.Com>
To: John Plocher 
Cc: Stefan Teleman , psarc-ext@sun.com
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;        d=gmail.com; s=beta;
 h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
 b=IO6i0F3WLldhHY8NQqW+eCJ3XMnmOfecPBy1twZUqihvddjDqcn6k7R9rbfSIn7fB1Z16QhvEJuYJgnGfhgEI6GC4qnaBsWcGMUwHRuiwIadqZMpOhD+VPDWaGpbztHGTl1c6vfgLec8h+e8Hoh7oV9xgxTNl1I39fuFBlvxM6Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;        d=gmail.com; s=beta;
 h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
 b=p2lEL1wb2sFhCP7DAq1S93kaZT0tGW5vKHL3/tLuBGzDCoAYrtfEj5eqRUc4Aldp0Sl6IqQ1T33HVTUbxnAumz3xFIGU/EBQEviQUf1Sdr9/PmjNsORUH0+2jrcewoBK+80/7nwfNM/JCGly7DjCtetSk1uMPOFU9WBJ9NCo+eg=
X-PMX-Version: 5.2.0.264296
References: 
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <460A7EDD.3030504@Sun.COM>
 <460A9A42.7030706@Sun.Com>
 
 <460BE312.1080203@Sun.Com>
Status: RO
Content-Length: 2656

On 3/29/07, John Plocher  wrote:
> Peter Tribble wrote:
> > So we need the ability for those underlying components to support both
> > the ability to rapidly update to a new version if desired, and the
> > ability to
> > pin a particular version in place for compatibility. And, epecially with
> > zones,
> > the ability to do both simultaneously on the same system.
>
> In your opinion, does the current updated proposal meet these needs?
> I think it does, but I'd like to make sure you do as well.

It's close, in that it supports the pinning of a particular version.
And supports multiple simultaneous versions, which is necessary.
Where I still have a problem is 6.4.2.0 (I think) where there's no
guarantee of updates. In that context, I expressly request that every PHP
version released be made available...

(The availability of such an update mechanism would pretty well be a
deal-breaker for deploying "vendor" supplied as opposed to in-house
build of PHP. I don't necessarily expect Solaris to supply it; opensolaris.org
could supply intermediate builds.)

> > [Peter added more user types]
> > 3) The user who has a production system that needs to migrate to the latest
> > released version for functionality, bugfix, or security reasons.
> >
> > (And generally, back-porting some subset of those fixes to the "stable"
> > release picked on isn't a valid solution.)
> >
> > 4) The user who has picked a solution to a problem and requires a
> > matching version of php to run it on. Or who needs to upgrade such
> > a solution and needs to upgrade the version of php to match.
>
> I /think/ that both of these needs are met if we continue to track
> a reasonable approximation of the latest stable community release.
> As Joe said, the best of all worlds is if the PHP community were to
> be the issuer for these packages, but it is also OK for some part of
> the OS.o community to do so instead.  Does this match your understanding?

Again, as long as somebody picks this up. If they don't, I can't use it and
have to take the responsibility myself.

> > In the case of php, is that aim to supply php as a language or as an
> > apache module? I've never come across it in use except as an apache
> > module, so is there any need to put php in the path or php libraries in
> > /usr/lib?
>
> 
> I think the majority use is in web pages, but there are development test
> scenerios that use the command line.  I don't think (and I don't wish to
> have) the command line interface to php needs to be in /usr/bin.
> 

Agreed.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

From jek3@sun.com Wed Apr  4 15:16:48 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34MGlOG004500
	for ; Wed, 4 Apr 2007 15:16:47 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l34MG6RZ009900;
	Thu, 5 Apr 2007 06:16:10 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JFZ00I05V6X2500@nwk-avmta-2.sfbay.sun.com>; Wed,
 04 Apr 2007 15:16:09 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFZ00GNVV6WMS40@nwk-avmta-2.sfbay.sun.com>; Wed,
 04 Apr 2007 15:16:08 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l34MG7Va485132;
 Wed, 04 Apr 2007 15:16:08 -0700 (PDT)
Date: Wed, 04 Apr 2007 12:15:37 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: Peter Tribble 
Cc: John Plocher ,
        Stefan Teleman , psarc-ext@sun.com
Message-id: <46142389.6030300@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: 
  <4609DF93.70709@sun.com>
 <20070328040915.GD1666@Sun.COM> <4609F6FC.4040609@sun.com>
 <460A2497.2060604@sun.com> <460A7EDD.3030504@Sun.COM>
 <460A9A42.7030706@Sun.Com>
 
 <460BE312.1080203@Sun.Com>
 
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1574

Peter Tribble wrote:
>> In your opinion, does the current updated proposal meet these needs?
>> I think it does, but I'd like to make sure you do as well.
>
> It's close, in that it supports the pinning of a particular version.
> And supports multiple simultaneous versions, which is necessary.
> Where I still have a problem is 6.4.2.0 (I think) where there's no
> guarantee of updates. In that context, I expressly request that every PHP
> version released be made available...
>
> (The availability of such an update mechanism would pretty well be a
> deal-breaker for deploying "vendor" supplied as opposed to in-house
> build of PHP. I don't necessarily expect Solaris to supply it; 
> opensolaris.org
> could supply intermediate builds.)
As a architectural review committee, we can't force a release schedule 
or mechanism.
We only approve what some project team proposes to do.

As I said in other mail, I doubt Sun will fund the "productization" of 
every PHP
release.  (I now realize I shouldn't have said that without knowing how 
far apart
the releases are.  At one or maybe two a year, it might happen.  Note 
that Gnome
happens every 6 months and we skip many (sometimes too many). Most linux
distros do the same.).

If this is done under opensolaris.org, I think all you need is somebody 
to step-up
to do it.

Thanks for your observation about the mysql extensions.  Remember, if 
they don't
happen in this proposal, they can easily be added in a subsequent proposal.

- thanks for your input, hearing from real users of this stuff is very 
helpful.

- jek3


From Stefan.Teleman@sun.com Thu Apr  5 10:05:35 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35H5ZQ4026042
	for ; Thu, 5 Apr 2007 10:05:35 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35H52hc017466;
	Thu, 5 Apr 2007 10:05:02 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100A03BGDWH00@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 11:05:01 -0600 (MDT)
Received: from jurassic.eng.sun.com ([129.146.58.37])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100JAKBGCO390@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 11:05:00 -0600 (MDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35H4wwA061550; Thu,
 05 Apr 2007 10:04:58 -0700 (PDT)
Date: Thu, 05 Apr 2007 13:04:32 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46141E07.30808@sun.com>
To: Joseph Kowalski 
Cc: Bill Sommerfeld , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <46152C20.4040204@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_ytLcFn0XLO0qwBiP13ZCxw)"
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 15066

This is a multi-part message in MIME format.

--Boundary_(ID_ytLcFn0XLO0qwBiP13ZCxw)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

Updated FastTrack attached.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


--Boundary_(ID_ytLcFn0XLO0qwBiP13ZCxw)
Content-type: text/plain; name=PHP5FastTrack.asc
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=PHP5FastTrack.asc

Including PHP5 with Solaris

Stefan Teleman 
15 March 2007

1.	Summary and motivation

	The inclusion of PHP5 in Solaris as a component of SAPP
	[Solaris, Apache, PostgreSQL, PHP] will address a current
	shortcoming of SMI's software portfolio.
	
	The absence in Solaris of a LAMP [Linux, Apache, MySQL, PHP]
	equivalent software stack has allowed Linux to create the
	perception that it is the operating environment of choice for
	web-based applications.

	This case seeks Micro/Patch Release Binding.
		
2.	Technical issues

	2.1.	Key objects.
		
	/usr/php5/[version]/bin/php
	/usr/php5/[version]/bin/php-config
	/usr/php5/[version]/bin/phpize

	/usr/php5/[version]/bin/64/php
	/usr/php5/[version]/bin/64/php-config
	/usr/php5/[version]/bin/64/phpize


	/usr/php5/[version]/lib/libphp5-5.2.0.so
	/usr/php5/[version]/lib/libphp5.so -> /usr/php5/[version]/lib/libphp5-5.2.0.so
	/usr/php5/[version]/lib/64/libphp5-5.2.0.so
	/usr/php5/[version]/lib/64/libphp5.so -> /usr/php5/[version]/lib/64/libphp5-5.2.0.so

	/usr/php5/[version]/etc/php.ini

	All other objects will be contained within the /usr/php5/[version]
	hierarchy.  This hierarchy will loosely track that of the publicly
	available version.

	This FastTrack proposes the integration of PHP Version 5.2.0.
	
	The version of PHP5 [5.2.0] proposed for integration is 64-bit clean
	and largefile aware. A 64-bit version of PHP5 is being considered for
	a future release.
	
	2.2.	Versioning
	
	The PHP5 development process follows the ubiquitous
	"continuous development" model, typical of many Open Source projects.
	Currently, two Releases of PHP coexist, and are still under active
	development: PHP4 and PHP5. Also, PHP6 is currently under active
	development, and is scheduled to be released sometime during 2007.
	None of these three Major Releases make any guarantees of API and
	ABI compatibility.
		
	The PHP versioning model has followed the ..
	model. The version of PHP5 proposed for inclusion in Solaris is PHP
	5.2.0.
	
	2.3.	Directory Naming and Structure
	
	The proposed directory layout for PHP5 is:
		/usr/php5/
			[version]/bin
			[version]/bin/64
			[version]/doc
			[version]/etc	
			[version]/include
			[version]/lib
			[version]/lib/64
			[version]/man
			[version]/modules/64
			[version]/share

	The detailed directory and file layout for PHP5 is provided in
	Addendum 1.

	2.4.	Packaging and Delivery

	The current proposal allows for the inclusion and coexistence
	of multiple versions of PHP by keeping each installation under
	a version-specific subdirectory. The following package naming
	convention is proposed:

		SUNWphp520root
		SUNWphp520core
		SUNWphp520usr
		SUNWphp520man
		SUNWphp520doc

	SUNWphp520root will deliver only one file, the system-wide PHP5
	configuration file for each particular PHP release:

		/etc/php5/[version]/php.ini

	SUNWphp520core will deliver the minimal filesystem objects for a
	functional PHP5 Apache installation:

		SUNWphp520core:

		/usr/php5/[version]/lib
		/usr/php5/[version]/lib/64
		/usr/php5/[version]/modules
		/usr/php5/[version]/modules/64

	SUNWphp520usr will deliver the additional userland and developer
	filesystem objects:

		SUNWphp520usr:

		/usr/php5/[version]/bin
		/usr/php5/[version]/bin/64
		/usr/php5/[version]/include
		/usr/php5/[version]/share

	SUNWphp520doc will deliver the full and complete PHP5
	documentation in HTML format.

	SUNWphp520man will deliver the available man pages for PHP5:

		/usr/share/man/man1/php.1
		/usr/php5/[version]/man/man1/php.1
		/usr/php5/[version]/man/man1/php-config.1
		/usr/php5/[version]/man/man1/phpize.1

3.	PHP5 Modules [Extensions].

	PHP supports a loadable module interface (known in PHP parlance
	as "Extensions"), allowing the PHP runtime to communicate with,
	and bind to, external interfaces. This module interface also allows
	for the clean integration of new PHP features or bindings. In addition,
	SMI may want to provide customers internally developed PHP Extensions.
	PHP Extensions have an associated dynamically loadable shared object
	(*.so). As mentioned earlier, PHP makes no guarantee of binary
	compatibility between releases. Maintaining PHP within the constraint
	of such possible binary incompatibilities motivates the directory
	layout structure proposed in 2.3.
		
	3.1.	PHP Core Modules.
	
	The initial integration will provide a subset of the PHP5
	Core Extensions as delivered by the canonical PHP5 Release:

		pcre [Perl-Compatible Regular Expressions]
		idn [International Domain Names Resolver]
		gd [Graphics Device]
		exif [EXIF Metadata Information]
		psql [PostgreSQL bindings]
		mbstring [Multi-Byte Strings/UTF Encoding bindings]
		gettext [GNU-compatible gettext binding]
		iconv [GNU compatible character encoding/conversion bindings]
		xml [XML bindings]
		pdo [PHP Database Objects bindings]
		pgsql [PostgreSQL bindings]
		soap [SOAP bindings]
		spl [Standard PHP Library]
		ssl [OpenSSL bindings]
		tcpwrap [TCPWrap bindings]
		tidy [HTML parsing and validation library]
		zlib [libz compression bindings]
		bz2 [libbz2 compression bindings]
		zip [libzip bindings]
		json [JavaScript bindings]
		bcmath [Binary Calculator Math bindings]
		calendar [Calendar bindings]
		ctype [Character bindings]
		curl [C-URL bindings]
		dom [DOM XSLT bindings]
		posix [POSIX bindings]
		sockets [libsocket bindings]
		session [PHP Session bindings]
		suhosin [Hardened PHP Extension]
		apc [Advanced PHP Caching Extension]

	Additional Extensions can be delivered subsequent to the initial
	PHP5 integration, depending on customer requests, and on the
	availability of the external dependencies required by these Extensions.

4.	PHP5 Internationalization.

	PHP5 provide basic I18N support via its ctype/gettext/iconv/mbstring
	Extensions. As an externally developed application, PHP5 will not
	provide additional Internationalization support beyond what is provided
	by the canonical distribution.

5.	PHP5 Documentation.

	PHP5 comes with an exhaustive set of documentation available in several
	languages from the PHP Site [http://www.php.net/docs.php] [2].

	5.1.	Full Adoption.

	The full PHP5 documentation is available for download from the PHP
	Site [http://www.php.net/download-docs.php] [3]. This documentation
	collection should be placed in the separate [doc] directory for each
	PHP5 Release [/usr/php5/[version]/doc].

	5.2.	Manual Pages.

	PHP5 provides a default man page [php(1)]. This man page will be
	delivered in the appropriate man directory [/usr/php5/[version]/man],
	with an appropriate symbolic link to /usr/php5/man. The contents of
	this man page is provided in Addendum 2.

	A generic man page will be delivered in the standard Solaris man
	directory (/usr/share/man/man1/php.1). This man page will follow
	the model introduced by Perl5 [PSARC 1999/192], and will provide
	a complete listing of available PHP5 man pages [php(1), phpize(1)
	and php-config(1)]. The contents of this man page is provided in
	Addendum 3.

6.	Interfaces

	6.1.	Interface Stability.

	PHP, as an Open Source project, is controlled by a group of developers
	external of, and independent from, SMI. The PHP Group makes no
	guarantees or promises of ABI or API compatibility between PHP releases.

	6.2.	Imported Interfaces.

	NAME				STABILITY		NOTES

	Apache 2.2 APR Libraries	Uncommitted		PSARC/2007/169
	OpenSSL	[Secure Sockets Layer]	External/Volatile	PSARC/2003/500
	PCRE [Perl-Compatible Regular Expressions] Uncommitted	PSARC/2007/164
	IDN [Internationalized Domain Library]	Uncommitted	PSARC/2007/167
	GD [Graphics Device Library]	Uncommitted		PSARC/2007/166
	EXIF [EXIF Metadata Information]	Uncommitted	LSARC/2006/202
	PostgreSQL			Uncommitted		LSARC/2006/655
	TCPWrap [TCP Wrappers Library]	Evolving		PSARC/2001/709
	Tidy [HTML Validation Library]	Uncommitted		PSARC/2007/134
	Z-lib [Zlib Compression Library]	Committed	PSARC/2006/537
	BZ2 [bz2 Compression Library]	Standard		PSARC/1999/555
	ZIP [Zip Compression Library]	Standard		PSARC/1999/555
	CURL [C-URL Library]		Uncommitted		PSARC/2007/165
	LibXML [XML Library]		Standard		PSARC/2001/175
	LibXSLT [XSLT Transformation Library]	Evolving	PSARC/2002/244
	LibFreetype 2 [Freetype Library]	External	LSARC/2005/397
	LibFontconfig [Fontconfig Library]	External	LSARC/2003/273

	6.3.	Exported Interfaces.

	PHP5 implements two types of Exported Interfaces. The first type
	[Type 1] is a one-to-one mappping between a physical filesystem
	object, and its associated Interfaces. The second type [Type 2] is
	a virtual mapping of two distinct Interface Objects: a physical
	filesystem object and an Interface moniker handle which may, or
	may not act as a provider of programmatic interface(s). Not all
	Type 2 Interfaces provide a programmatic interface. Typically,
	but not always, Type 2 Interfaces which do not provide a programmatic
	interface, provide a configuration interface via the php.ini file.

	This Type 2 Interface is characteristic of PHP5's Extensions.
	Also characteristic of the Type 2 Interface is the property
	that physical filesystem object Interfaces are always Private and
	implicitly Volatile, whereas their corresponding programmatic, or
	configuration interfaces, if they exist, are public and Uncommitted.

	NAME			STABILITY		NOTES

	SUNWphp520core		Uncommitted		Package Name
	SUNWphp520usr		Uncommitted		Package Name
	SUNWphp520man		Uncommitted		Package Name
	SUNWphp520doc		Uncommitted		Package Name

	/usr/php5/[version]/bin/php	Uncommitted	Executable location
	/usr/php5/[version]/bin/64/php	Uncommitted	Executable location

	/usr/php5/[version]/bin/phpize	Uncommitted	Executable location
	/usr/php5/[version]/bin/64/phpize	Uncommitted	Executable location

	/usr/php5/[version]/bin/php-config	Uncommmited	Executable location
	/usr/php5/[version]/bin/64/php-config	Uncommmited	Executable location

	/etc/php5/[version]/php.ini	Uncommitted	Configuration file

	/usr/php5/[version]/lib/libphp5-[version].so	Uncommitted	PHP Library
	/usr/php5/[version]/lib/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic link
	/usr/php5/[version]/lib/64/libphp5-[version].so Uncommitted	PHP Library
	/usr/php5/[version]/lib/64/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic Link

	apc	Uncommitted	APC Extension
	bcmath	Uncommitted	BC Math Extension
	bz2	Uncommitted	BZ2 Extension
	calendar Uncommitted	Calendar Extension
	ctype	Uncommitted	Character Extension
	curl	Uncommitted	C-URL Extension
	dba	Uncommitted	Database Access Extension
	dom	Uncommitted	XML DOM Extension
	dtrace	Uncommitted	DTrace Extension
	exif	Uncommitted	EXIF Extension
	filter	Uncommitted	Filter Extension
	ftp	Uncommitted	FTP Extension
	gd	Uncommitted	GD Extension
	gettext	Uncommitted	Gettext Extension
	hash	Uncommitted	PHP Hashing Extension
	iconv	Uncommitted	GNU Iconv Compatible Extension
	json	Uncommitted	JavaScript Object Notation Extension
	libxml	Uncommitted	LibXML Extension
	mbstring	Uncommitted	Multi-byte Strings Extension
	openssl	Uncommitted	OpenSSL Extension
	pcntl	Uncommitted	Process Control Extension
	pcre	Uncommitted	PCRE Extension
	pdo	Uncommitted	PHP Database Objects Extension
	pdo_pgsql	Uncommitted	PostgreSQL PHP Database Objects Extension
	pgsql	Uncommitted	PHP PostgreSQL Native Extension
	posix	Uncommitted	PHP POSIX Emulation Extension
	session	Uncommitted	PHP Session Management Extension
	shmop	Uncommitted	PHP Shared Memory Extension
	simplexml	Uncommitted	PHP XML Extension
	soap	Uncommitted	PHP SOAP Extension
	sockets	Uncommitted	PHP Sockets Extension
	spl	Uncommitted	Standard PHP Library Extension
	suhosin	Uncommitted	Hardened PHP Security Extension
	sysvmsg	Uncommitted	SVR4 IPC Extension
	sysvsem	Uncommitted	SVR4 Semaphores Extension
	sysvshm	Uncommitted	SVR4 Shared memory Extension
	tcpwrap	Uncommitted	TCP Wrapper Library Extension
	tidy	Uncommitted	TIDY Library Extension
	tokenizer	Uncommitted	PHP Tokenizer Parser Extension
	xml	Uncommitted	LibXML Extension
	xlmreader	Uncommitted	LibXML Reader Extension
	xmlrpc	Uncommitted	LibXML RPC Extension
	xmlwriter	Uncommitted	LibXML Writer Extension
	xsl	Uncommitted	LibXSLT Extension
	zip	Uncommitted	ZIP Compression Extension
	zlib	Uncommitted	ZLib Compression Extension

	6.4.	Maintaining Interface Compatibility

	PHP does not make any guarantees of Interface Stability between
	minor or major releases. To wit, interface compatibility between
	PHP 5.1.6 and PHP 5.2.0 has been broken. In order to reconcile
	this inherent interface instability with Solaris' interface
	stability constraints, we propose the following set of assumptions
	and rules governing existing PHP updates and new PHP releases :

		6.4.1.	Assumptions

		No API or ABI Compatibility is implied, or is to be assumed,
		or inferred, between Major, Minor, or Micro PHP Releases.

		6.4.2.	Consequences And Ensuing Constraints

		0.	A new version of PHP will be introduced in Solaris if
		and when it provides a significant set of new functionality,
		or facilities, and when such facilities are of interest to,
		or have been expressly requested by, the Community.

		1.	Future upgrades of PHP from the version specified in
		this document must follow the standard FastTrack ARC approval
		process.

		2.	Once a PHP version has shipped, either in a "FCS" or
		an "Update" Solaris release, it will not be removed, for the
		lifetime of this particular Release. It may, however, be
		updated or patched, and it may introduce new functionality
		and/or facilities, provided that the Interface Stability
		Constraints controlling this PHP version are respected. An
		exception to this Constraint is explicitly granted to security
		patches or upgrades.

		3.	A new version of PHP may be introduced in a patch, or
		in a "FCS" or "Upgrade" Solaris Release. It is mandated that
		Binary Incompatible Releases of PHP reside in their own,
		separate, directory trees, thereby observing the Interface
		Stability Constraints enforced by any previous [existing] PHP
		Releases.

7.	References.

	[1]	http://www.php.net/
	[2]	http://www.php.net/docs.php
	[3]	http://www.php.net/download-docs.php
	[4]	http://www.php.net/license/3_01.txt
	[5]	http://bugs.php.net/
	[6]	http://www.libgd.org/
	[7]	http://curl.haxx.se/
	[8]	http://www.pcre.org/
	[9]	http://tidy.sourceforge.net/
	[10]	http://sourceforge.net/project/showfiles.php?group_id=12272
	[11]	http://www.littlecms.com/
	[12]	http://www.gnu.org/software/libidn/
	[13]	http://www.hardened-php.net/
	[14]	http://www.postgresql.org/
	[15]	http://www.apache.org/
	[16]	http://www.xmlsoft.org/
	[17]	http://www.openssl.org/
	

--Boundary_(ID_ytLcFn0XLO0qwBiP13ZCxw)--

From jek3@sun.com Thu Apr  5 11:44:06 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35Ii6G5028901
	for ; Thu, 5 Apr 2007 11:44:06 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35IhYpd017270;
	Thu, 5 Apr 2007 11:43:34 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100K01G0LI700@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 12:43:33 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100JVFG0LO3E0@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 12:43:33 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l35IhVjB658547;
 Thu, 05 Apr 2007 11:43:32 -0700 (PDT)
Date: Thu, 05 Apr 2007 08:43:01 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46152C20.4040204@Sun.COM>
To: Stefan Teleman 
Cc: Bill Sommerfeld , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <46154335.90702@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 667

Stefan Teleman wrote:
> 	/usr/php5/[version]/lib/libphp5-[version].so	Uncommitted	PHP Library
> 	/usr/php5/[version]/lib/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic link
> 	/usr/php5/[version]/lib/64/libphp5-[version].so Uncommitted	PHP Library
> 	/usr/php5/[version]/lib/64/libphp5.so -> libphp5-[version].so	Uncommitted	Symbolic Link
>   
Were my assumptions that its really SONAME that we are committing to 
incorrect?

If so, I THINK we need to THINK about the consequences of this.  With 
the version in the PATH, a version in the SONAME may be acceptable.  
However, it makes my head hurt to think about it.

Otherwise, I'm content.

RSVP,

- jek3


From Stefan.Teleman@sun.com Thu Apr  5 12:20:19 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35JKIIT029447
	for ; Thu, 5 Apr 2007 12:20:19 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35JJbdK026841;
	Thu, 5 Apr 2007 20:19:39 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100D0XHOP8200@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 12:19:37 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.17.55])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100BUQHOPE700@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 12:19:37 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35JJIgf075120; Thu,
 05 Apr 2007 12:19:22 -0700 (PDT)
Date: Thu, 05 Apr 2007 15:19:16 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46154335.90702@sun.com>
To: Joseph Kowalski 
Cc: Bill Sommerfeld , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <46154BB4.7070603@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 2237



Joseph Kowalski wrote:
> Stefan Teleman wrote:
>>     /usr/php5/[version]/lib/libphp5-[version].so    Uncommitted    PHP 
>> Library
>>     /usr/php5/[version]/lib/libphp5.so -> libphp5-[version].so    
>> Uncommitted    Symbolic link
>>     /usr/php5/[version]/lib/64/libphp5-[version].so Uncommitted    PHP 
>> Library
>>     /usr/php5/[version]/lib/64/libphp5.so -> libphp5-[version].so    
>> Uncommitted    Symbolic Link
>>   
> Were my assumptions that its really SONAME that we are committing to 
> incorrect?
> 
> If so, I THINK we need to THINK about the consequences of this.  With 
> the version in the PATH, a version in the SONAME may be acceptable.  
> However, it makes my head hurt to think about it.

In this particular case, the SONAME (libphp5.so) is only relevant to one other 
application: Apache (since libphp5.so is the SONAME expected by APR to load it 
as an Apache Module). The php executable links against libphp5.so, but this is 
determined by RPATH.

Noone else should explicitly link against this library. If somoeone wants to 
write a PHP Extension, they do not need to, and should *not* explicitly link 
against this particular version of the PHP Library, or any other version for 
that matter. Explicit linking against libphp5.so is simply Verboten. [if this 
wasn't a stern warning, then i don't know what is :-)]. PHP Extensions are 
dlopen()' ed by libphp5.so, and they should never depend on a particular version 
of libphp5.so.

So, the SONAME is only relevant to Apache (and to the php executable, but this 
is a private matter between php and libphp5.so). However, this SONAME will be 
preserved across PHP5 releases -- meaning PHP 5.3.x's and/or PHP 5.4.x's shared 
library will still have a SONAME of libphp5.so.

At the same time, i do not believe that a classification of Project Private, or 
Volatile is appropriate for libphp5.so, due to the Apache relationship explained 
above. Apache's relationship to PHP is one-to-many (Apache doens't care which 
particular version of libphp5.so is loaded as a module, several versions might 
be available, and Apache is explicitly told to load one, and only one of them).

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Thu Apr  5 14:23:22 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35LNMgj003648
	for ; Thu, 5 Apr 2007 14:23:22 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35LMaSn024605;
	Thu, 5 Apr 2007 22:22:46 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100029NDVIK00@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 14:22:43 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100BQ4NDSEM60@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 14:22:40 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l35LMdWO690479;
 Thu, 05 Apr 2007 14:22:39 -0700 (PDT)
Date: Thu, 05 Apr 2007 11:22:08 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46154BB4.7070603@Sun.COM>
To: Stefan Teleman 
Cc: Bill Sommerfeld , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <46156880.7020008@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 2590

Stefan Teleman wrote:
>
>
> Joseph Kowalski wrote:
>> Stefan Teleman wrote:
>>>     /usr/php5/[version]/lib/libphp5-[version].so    Uncommitted    
>>> PHP Library
>>>     /usr/php5/[version]/lib/libphp5.so -> libphp5-[version].so    
>>> Uncommitted    Symbolic link
>>>     /usr/php5/[version]/lib/64/libphp5-[version].so Uncommitted    
>>> PHP Library
>>>     /usr/php5/[version]/lib/64/libphp5.so -> libphp5-[version].so    
>>> Uncommitted    Symbolic Link
>>>   
>> Were my assumptions that its really SONAME that we are committing to 
>> incorrect?
>>
>> If so, I THINK we need to THINK about the consequences of this.  With 
>> the version in the PATH, a version in the SONAME may be acceptable.  
>> However, it makes my head hurt to think about it.
>
> In this particular case, the SONAME (libphp5.so) is only relevant to 
> one other application: Apache (since libphp5.so is the SONAME expected 
> by APR to load it as an Apache Module). The php executable links 
> against libphp5.so, but this is determined by RPATH.
>
> Noone else should explicitly link against this library. If somoeone 
> wants to write a PHP Extension, they do not need to, and should *not* 
> explicitly link against this particular version of the PHP Library, or 
> any other version for that matter. Explicit linking against libphp5.so 
> is simply Verboten. [if this wasn't a stern warning, then i don't know 
> what is :-)]. PHP Extensions are dlopen()' ed by libphp5.so, and they 
> should never depend on a particular version of libphp5.so.
>
> So, the SONAME is only relevant to Apache (and to the php executable, 
> but this is a private matter between php and libphp5.so). However, 
> this SONAME will be preserved across PHP5 releases -- meaning PHP 
> 5.3.x's and/or PHP 5.4.x's shared library will still have a SONAME of 
> libphp5.so.
>
> At the same time, i do not believe that a classification of Project 
> Private, or Volatile is appropriate for libphp5.so, due to the Apache 
> relationship explained above. Apache's relationship to PHP is 
> one-to-many (Apache doens't care which particular version of 
> libphp5.so is loaded as a module, several versions might be available, 
> and Apache is explicitly told to load one, and only one of them).
>
> --Stefan
Oh bummer.

This is a bit interesting.  Before I go further, let me ask a 
clarification question:

Its quite possible that an Apache downloaded from apache.org would want 
to link against the PHP5 delivered with Solaris, right?
Its not just the Apache delivered with Solaris that might link against this.

- thanks,

- jek3


From Stefan.Teleman@Sun.COM Thu Apr  5 14:42:33 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35LgW5R003775
	for ; Thu, 5 Apr 2007 14:42:32 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l35Lfpxw002164;
	Fri, 6 Apr 2007 05:41:55 +0800 (SGT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100F0DO9S4F00@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 15:41:52 -0600 (MDT)
Received: from jurassic.eng.sun.com ([129.146.108.31])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100CB6O9RV980@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 15:41:52 -0600 (MDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35LfoGC080345; Thu,
 05 Apr 2007 14:41:50 -0700 (PDT)
Date: Thu, 05 Apr 2007 17:41:47 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46156880.7020008@sun.com>
To: Joseph Kowalski 
Cc: Bill Sommerfeld , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@Sun.COM
Reply-to: Stefan Teleman 
Message-id: <46156D1B.6070405@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 1407



Joseph Kowalski wrote:

> Oh bummer.
> 
> This is a bit interesting.  Before I go further, let me ask a 
> clarification question:
> 
> Its quite possible that an Apache downloaded from apache.org would want 
> to link against the PHP5 delivered with Solaris, right?
> Its not just the Apache delivered with Solaris that might link against 
> this.

Oh, no, never. Apache never links explicitly against libphp5.so (as in -lphp5). 
Insofar as Apache is concerned, libphp5.so is an "Apache Module". This means it 
is dlopen()'ed by Apache as a result of an explicit LoadModule directive in 
httpd.conf:

LoadModule	php5_module	modules/libphp5.so

So, no matter where Apache is downloaded from (or built), it can only load 
libphp5.so as an Apache Module.

Caveat: libphp5.so does have an intimate (and undisclosed) relationship with 
Apache, consumed at libphp5.so compile time: PHP's ./configure *knows* how 
Apache was built, because it retrieves this information from Apache's apxs at 
./configure time. The result of this private relationship is that, if someone 
downloads an Apache build from somewhere else, and this Apache build is not 
identical to our Apache build, libphp5.so might misbehave.

The conclusion is that, in reality, a particular PHP build is connected to the 
Apache build which was used in building PHP.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Thu Apr  5 14:56:17 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35LuH9I004488
	for ; Thu, 5 Apr 2007 14:56:17 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35Ltit2020245;
	Thu, 5 Apr 2007 14:55:44 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100G01OWWOT00@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 15:55:44 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100CKROWVV9C0@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 15:55:44 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l35LtgFJ696088;
 Thu, 05 Apr 2007 14:55:42 -0700 (PDT)
Date: Thu, 05 Apr 2007 11:55:12 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46156D1B.6070405@Sun.COM>
To: Stefan Teleman 
Cc: Bill Sommerfeld , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <46157040.6040002@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 2547


I NEED THE REST OF THE ARC TO START PAYING ATTENTION HERE.

Stefan, relax... we just got to figure out how to classify this stuff.  
I think its up to the ARC (or the case owner) to figure this out.  
You'll probably just end up be sent text to cut into the spec and we'll 
be done.

If I interpret this right, the apache community and the php community 
have what appears to be the equivalent of a contracted consolidation 
private interface between their two consolidations/communities.  I have 
no idea how we map this into our taxonomy.

One option is that we officially call it Consolidation Private (so we 
don't feel obligated to document it) and note the unholy relationship 
between these communities and just live with it.

Another option would be to leave these as Uncommitted, but note (that 
for the same reasons as above) that these are exempt from the 
documentation requirement.  The only "Public" involved is the Apache 
community.

I think I favor the second option, because it seems less likely to lead 
to mistakes because somebody fails to read the small print.

Preferences or other suggestions?

- jek3


Stefan Teleman wrote:
> Joseph Kowalski wrote:
>
>> Oh bummer.
>>
>> This is a bit interesting.  Before I go further, let me ask a 
>> clarification question:
>>
>> Its quite possible that an Apache downloaded from apache.org would 
>> want to link against the PHP5 delivered with Solaris, right?
>> Its not just the Apache delivered with Solaris that might link 
>> against this.
>
> Oh, no, never. Apache never links explicitly against libphp5.so (as in 
> -lphp5). Insofar as Apache is concerned, libphp5.so is an "Apache 
> Module". This means it is dlopen()'ed by Apache as a result of an 
> explicit LoadModule directive in httpd.conf:
>
> LoadModule    php5_module    modules/libphp5.so
>
> So, no matter where Apache is downloaded from (or built), it can only 
> load libphp5.so as an Apache Module.
>
> Caveat: libphp5.so does have an intimate (and undisclosed) 
> relationship with Apache, consumed at libphp5.so compile time: PHP's 
> ./configure *knows* how Apache was built, because it retrieves this 
> information from Apache's apxs at ./configure time. The result of this 
> private relationship is that, if someone downloads an Apache build 
> from somewhere else, and this Apache build is not identical to our 
> Apache build, libphp5.so might misbehave.
>
> The conclusion is that, in reality, a particular PHP build is 
> connected to the Apache build which was used in building PHP.
>
> --Stefan


From Stefan.Teleman@Sun.COM Thu Apr  5 15:03:18 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35M3HHH004526
	for ; Thu, 5 Apr 2007 15:03:18 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35M2bZf002890;
	Thu, 5 Apr 2007 23:02:42 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG10033YP8I6I00@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 15:02:42 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.58.37])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100BIRP8GEM80@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 15:02:40 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35M2FMl081251; Thu,
 05 Apr 2007 15:02:15 -0700 (PDT)
Date: Thu, 05 Apr 2007 18:02:09 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46157040.6040002@sun.com>
To: Joseph Kowalski 
Cc: Bill Sommerfeld , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@Sun.COM
Reply-to: Stefan Teleman 
Message-id: <461571E1.6080201@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 1562



Joseph Kowalski wrote:
> 
> I NEED THE REST OF THE ARC TO START PAYING ATTENTION HERE.
> 
> Stefan, relax... we just got to figure out how to classify this stuff.  
> I think its up to the ARC (or the case owner) to figure this out.  
> You'll probably just end up be sent text to cut into the spec and we'll 
> be done.

Okies. I am relaxed. :-)

> If I interpret this right, the apache community and the php community 
> have what appears to be the equivalent of a contracted consolidation 
> private interface between their two consolidations/communities.  I have 
> no idea how we map this into our taxonomy.
> 
> One option is that we officially call it Consolidation Private (so we 
> don't feel obligated to document it) and note the unholy relationship 
> between these communities and just live with it.
> 
> Another option would be to leave these as Uncommitted, but note (that 
> for the same reasons as above) that these are exempt from the 
> documentation requirement.  The only "Public" involved is the Apache 
> community.
> 
> I think I favor the second option, because it seems less likely to lead 
> to mistakes because somebody fails to read the small print.

I would also prefer the second option, for exact the same reasons as yours. In 
fact, libphp5.so is, for all practical purposes, "Consolidation Private", since 
noone is supposed to link to it. Only Apache is supposed to know about it, and 
only because Apache is being expicitly told to know about it.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From sommerfeld@sun.com Thu Apr  5 15:11:48 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35MBlmD004689
	for ; Thu, 5 Apr 2007 15:11:48 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35MB8IR003798;
	Thu, 5 Apr 2007 23:11:13 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100I01PMODB00@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 16:11:13 -0600 (MDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100H0GPMOJO10@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 16:11:12 -0600 (MDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l35MB9M7006109; Thu, 05 Apr 2007 18:11:10 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35MB9BL006642; Thu,
 05 Apr 2007 18:11:09 -0400 (EDT)
Date: Thu, 05 Apr 2007 18:11:08 -0400
From: Bill Sommerfeld 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <461571E1.6080201@Sun.COM>
To: Stefan Teleman 
Cc: Joseph Kowalski , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <1175811068.4423.80.camel@thunk>
MIME-version: 1.0
X-Mailer: Evolution 2.8.1.1
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM>
Status: RO
Content-Length: 996

On Thu, 2007-04-05 at 18:02 -0400, Stefan Teleman wrote:
> > One option is that we officially call it Consolidation Private (so we 
> > don't feel obligated to document it) and note the unholy relationship 
> > between these communities and just live with it.

I think this more faithfully reflects the actual relationship between
the two modules and is my preference for where there isn't an ABI and
you need a carefully matched pair of modules.

(our taxonomy doesn't really cover cases where there is source
compatibility but not ABI compatibility between two different versions
or implementations of an interface).

> I would also prefer the second option, for exact the same reasons as yours. In 
> fact, libphp5.so is, for all practical purposes, "Consolidation Private", since 
> noone is supposed to link to it. Only Apache is supposed to know about it, and 
> only because Apache is being expicitly told to know about it.

I thought the second option was "Uncommitted"..

						- Bill



From Stefan.Teleman@Sun.COM Thu Apr  5 15:17:07 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35MH72F004763
	for ; Thu, 5 Apr 2007 15:17:07 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35MGXOO023571;
	Thu, 5 Apr 2007 15:16:34 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100415PVL6I00@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 15:16:33 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.56.144])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100BQ2PVJE780@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 15:16:31 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35MGUYT082845; Thu,
 05 Apr 2007 15:16:30 -0700 (PDT)
Date: Thu, 05 Apr 2007 18:16:27 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <1175811068.4423.80.camel@thunk>
To: Bill Sommerfeld 
Cc: Joseph Kowalski , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@Sun.COM
Reply-to: Stefan Teleman 
Message-id: <4615753B.6030006@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <1175811068.4423.80.camel@thunk>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 299



Bill Sommerfeld wrote:

> I thought the second option was "Uncommitted"..

Yes, i meant leaving it officially as "Uncommitted" (and abide by these 
constraints), but treating it, in practice, as "Consolidation Private".

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From sommerfeld@sun.com Thu Apr  5 15:55:22 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35MtLYw005703
	for ; Thu, 5 Apr 2007 15:55:21 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l35MsaaV017747;
	Fri, 6 Apr 2007 06:54:46 +0800 (SGT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100N01RN83000@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 16:54:44 -0600 (MDT)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100HD2RN7JM50@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 16:54:43 -0600 (MDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l35MsfaJ001206; Thu, 05 Apr 2007 18:54:41 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35Msexu006928; Thu,
 05 Apr 2007 18:54:40 -0400 (EDT)
Date: Thu, 05 Apr 2007 18:54:39 -0400
From: Bill Sommerfeld 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <4615753B.6030006@Sun.COM>
To: Stefan Teleman 
Cc: Joseph Kowalski , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <1175813679.6761.5.camel@thunk>
MIME-version: 1.0
X-Mailer: Evolution 2.8.1.1
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <1175811068.4423.80.camel@thunk>
 <4615753B.6030006@Sun.COM>
Status: RO
Content-Length: 789

On Thu, 2007-04-05 at 18:16 -0400, Stefan Teleman wrote:
> 
> Bill Sommerfeld wrote:
> 
> > I thought the second option was "Uncommitted"..
> 
> Yes, i meant leaving it officially as "Uncommitted" (and abide by these 
> constraints), but treating it, in practice, as "Consolidation Private".

that would mean we would be telling anyone they're allowed to use it and
it won't change incompatibly except at minor release boundaries, but in
practice we'll be changing it incompatably any time we feel like it.

that seems backwards.  how about treating it officially as Consolidation
Private (random consumers shouldn't use it and if they do and it breaks,
they get to keep both pieces) but in practice as Uncommitted (changes
incompatibly only at Minor release boundaries).

					- Bill





From Stefan.Teleman@sun.com Thu Apr  5 15:59:13 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35MxCPW005924
	for ; Thu, 5 Apr 2007 15:59:12 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35MwL8N018274;
	Thu, 5 Apr 2007 23:58:36 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100003RTMBK00@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 16:58:34 -0600 (MDT)
Received: from jurassic.eng.sun.com ([129.146.228.50])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100HB9RTLJK80@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 16:58:33 -0600 (MDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35MwStQ083880; Thu,
 05 Apr 2007 15:58:29 -0700 (PDT)
Date: Thu, 05 Apr 2007 18:58:26 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <1175813679.6761.5.camel@thunk>
To: Bill Sommerfeld 
Cc: Joseph Kowalski , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <46157F12.8010207@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <1175811068.4423.80.camel@thunk>
 <4615753B.6030006@Sun.COM> <1175813679.6761.5.camel@thunk>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 897



Bill Sommerfeld wrote:
> On Thu, 2007-04-05 at 18:16 -0400, Stefan Teleman wrote:
>> Bill Sommerfeld wrote:
>>
>>> I thought the second option was "Uncommitted"..
>> Yes, i meant leaving it officially as "Uncommitted" (and abide by these 
>> constraints), but treating it, in practice, as "Consolidation Private".
> 
> that would mean we would be telling anyone they're allowed to use it and
> it won't change incompatibly except at minor release boundaries, but in
> practice we'll be changing it incompatably any time we feel like it.

We can't change it incompatibly any time we want. That's the whole point of the 
PHP case following the Perl5 model (allowing different versions of PHP to 
coexist in separate directories).

We introduced precisely these constraints in the last two updates to the PHP 
FastTrack.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From danek.duvall@sun.com Thu Apr  5 16:01:32 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35N1WrJ006045
	for ; Thu, 5 Apr 2007 16:01:32 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35N0xO6020286;
	Thu, 5 Apr 2007 17:00:59 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100809RXMDL00@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 16:00:58 -0700 (PDT)
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100BHZRXKEGA0@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 16:00:56 -0700 (PDT)
Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40])
	by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l35N0tE1011349; Thu, 05 Apr 2007 16:00:55 -0700 (PDT)
Received: from zruty.sfbay.sun.com (localhost [127.0.0.1])
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l35MNLIU017538; Thu,
 05 Apr 2007 15:23:21 -0700 (PDT)
Received: (from dduvall@localhost)
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l35MNLht017537; Thu,
 05 Apr 2007 15:23:21 -0700 (PDT)
Date: Thu, 05 Apr 2007 15:23:20 -0700
From: Danek Duvall 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <461571E1.6080201@Sun.COM>
To: Stefan Teleman 
Cc: Joseph Kowalski , Bill Sommerfeld ,
        David Comay , Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <20070405222320.GI1864@zruty.sfbay.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM>
User-Agent: mutt-ng/devel-r535 (SunOS)
Status: RO
Content-Length: 2658

On Thu, Apr 05, 2007 at 06:02:09PM -0400, Stefan Teleman wrote:

> Joe Kowalski wrote:
>
> >If I interpret this right, the apache community and the php community
> >have what appears to be the equivalent of a contracted consolidation
> >private interface between their two consolidations/communities.  I have
> >no idea how we map this into our taxonomy.
> >
> >One option is that we officially call it Consolidation Private (so we
> >don't feel obligated to document it) and note the unholy relationship
> >between these communities and just live with it.
> >
> >Another option would be to leave these as Uncommitted, but note (that
> >for the same reasons as above) that these are exempt from the
> >documentation requirement.  The only "Public" involved is the Apache
> >community.  I think I favor the second option, because it seems less
> >likely to lead to mistakes because somebody fails to read the small
> >print.
> 
> I would also prefer the second option, for exact the same reasons as
> yours. In fact, libphp5.so is, for all practical purposes, "Consolidation
> Private", since noone is supposed to link to it. Only Apache is supposed
> to know about it, and only because Apache is being expicitly told to know
> about it.

It seems to me that the only Public interface that PHP exports from this
dynamic object is the filename of the object.  The SONAME and all of its
internal interfaces are strictly Private (Consolidation Private in the
context of the PHP community, but Project Private in the context of Sun,
via this project / ARC case).  The Public-ness here simply means that a
customer can add the string "libphp5.so" to an Apache configuration file
and expect that Apache will be able to load it as a module.  That sounds
Committed to me -- when we decide to stop shipping any flavor of PHP5, then
we go through an EOL process, which sounds reasonable.

The dynamic object uses interfaces provided by Apache so that it can
function as an Apache module.  These are the interfaces based on "unholy
knowledge" as you and Joe are talking about.  These have some stability
level that is defined by Apache, and not this project, and I don't think
are really relevant for this case, and certainly wouldn't show up in any
documentation related to this case, since we don't document a project's
imported interfaces.

This project should care about those interfaces only in how much they can
rely on them.  I would consider them to be either Volatile or Project
Private, and a contract would be needed in either case, but perhaps they're
Uncommitted (which I guess also needs a contract, right?).

Does that make sense to anyone but me?

Danek

From Stefan.Teleman@sun.com Thu Apr  5 16:21:53 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35NLqev007051
	for ; Thu, 5 Apr 2007 16:21:52 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l35NLExf023541;
	Fri, 6 Apr 2007 07:21:15 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG100A0FSVE1900@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 16:21:14 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.228.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100B7VSV5EKB0@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 05 Apr 2007 16:21:05 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35NKsEZ089562; Thu,
 05 Apr 2007 16:20:54 -0700 (PDT)
Date: Thu, 05 Apr 2007 19:20:48 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070405222320.GI1864@zruty.sfbay.sun.com>
To: Danek Duvall 
Cc: Joseph Kowalski , Bill Sommerfeld ,
        David Comay , Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <46158450.7080908@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 1948



Danek Duvall wrote:

> It seems to me that the only Public interface that PHP exports from this
> dynamic object is the filename of the object. 

Plus the required glue to make libphp5.so identify itself to Apache as an Apache 
Module [which is done at PHP ./configure time].


> This project should care about those interfaces only in how much they can
> rely on them.  I would consider them to be either Volatile or Project
> Private, and a contract would be needed in either case, but perhaps they're
> Uncommitted (which I guess also needs a contract, right?).
> 
> Does that make sense to anyone but me?

Yes it does. I think we're down to reconciling the following set of constraints:

0. libphp5.so's Exported Interfaces are, in fact, Project Private.
1. libphp5.so is an integral component of an Integration which tries to be 
Uncommitted, because Volatile or Project Private would allow for the removal of 
this object, or for the binary incompatible update of this object. This 
integration wants a stronger Stability Level.
2. Apache has a hard dependency on libphp5.so's Exported Interfaces, because it 
may want to load it as an Apache Module.
3. PHP has a hard dependency on Apache's Exported Interfaces.

The weird contradiction in all this is that, Apache doesn't need a Contract from 
PHP, because the appropriate Apache Module Interfaces will always be present in 
libphp5.so [while keeping Apache constant]. It's PHP  who needs a contract from 
Apache, because PHP is bound to the Interfaces exported by Apache at the time 
PHP was ./configure'd. Apache needs to promise PHP that it won't change. Apache 
doesn't care if PHP has changed. But, if we make PHP Volatile or Project 
Private, it can't ask for a Contract from an API which has a stronger (higher) 
Stability Level -- in this particular case, Apache's Commitment Level being 
Uncommitted.

--Stefan


-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Thu Apr  5 16:45:41 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35NjfE2007330
	for ; Thu, 5 Apr 2007 16:45:41 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35Nj24I029000;
	Thu, 5 Apr 2007 16:45:08 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG10050XTZ66A00@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 17:45:06 -0600 (MDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG100HIUTZ6JOC0@brm-avmta-1.central.sun.com>; Thu,
 05 Apr 2007 17:45:06 -0600 (MDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l35Nj5Et709783;
 Thu, 05 Apr 2007 16:45:05 -0700 (PDT)
Date: Thu, 05 Apr 2007 13:44:33 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <1175813679.6761.5.camel@thunk>
To: Bill Sommerfeld 
Cc: Stefan Teleman , David Comay ,
        Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <461589E1.4070009@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <460C66C8.602@Sun.COM> <4611441B.9000509@Sun.COM>
 <4612C51A.50506@sun.com> <4612F9F2.9070704@Sun.COM> <4613089B.1010102@sun.com>
 <1175653217.1001.241.camel@thunk> <46130D01.1020909@sun.com>
 <4613D202.7070300@Sun.COM> <4613F286.6010506@sun.com>
 <46140351.5070405@Sun.COM> <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <1175811068.4423.80.camel@thunk>
 <4615753B.6030006@Sun.COM> <1175813679.6761.5.camel@thunk>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1167

Bill Sommerfeld wrote:
> On Thu, 2007-04-05 at 18:16 -0400, Stefan Teleman wrote:
>   
>> Bill Sommerfeld wrote:
>>
>>     
>>> I thought the second option was "Uncommitted"..
>>>       
>> Yes, i meant leaving it officially as "Uncommitted" (and abide by these 
>> constraints), but treating it, in practice, as "Consolidation Private".
>>     
>
> that would mean we would be telling anyone they're allowed to use it and
> it won't change incompatibly except at minor release boundaries, but in
> practice we'll be changing it incompatably any time we feel like it.
>   
I don't think so.  Because of the version in the directory path, we 
won't be changing
it.  That's why Uncommitted appealed to me.  It actually reflects the 
when it might
change bit.  It doesn't correctly reflect who can use it.
> that seems backwards.  how about treating it officially as Consolidation
> Private (random consumers shouldn't use it and if they do and it breaks,
> they get to keep both pieces) but in practice as Uncommitted (changes
> incompatibly only at Minor release boundaries).
>   
This is what is intended to happen.  Its just a question of what we call it.

- jek3



From David.Comay@sun.com Fri Apr  6 10:03:20 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36H3K8h022645
	for ; Fri, 6 Apr 2007 10:03:20 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l36H2kLb006590;
	Fri, 6 Apr 2007 10:02:46 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG300K3H60MND00@brm-avmta-1.central.sun.com>; Fri,
 06 Apr 2007 11:02:46 -0600 (MDT)
Received: from izimbra.SFBay.Sun.COM ([129.146.226.141])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG300IUS60JMC10@brm-avmta-1.central.sun.com>; Fri,
 06 Apr 2007 11:02:43 -0600 (MDT)
Received: from localhost (localhost [127.0.0.1])
	by izimbra.SFBay.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l36H2a4I108451;
 Fri, 06 Apr 2007 10:02:36 -0700 (PDT)
Date: Fri, 06 Apr 2007 10:02:36 -0700 (PDT)
From: David.Comay@sun.com
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070405222320.GI1864@zruty.sfbay.sun.com>
Sender: comay@izimbra.sfbay.sun.com
To: Danek Duvall 
Cc: Stefan Teleman ,
        Bart Smaalders , psarc-ext@sun.com,
        Fred Thornborrow ,
        Joseph Kowalski 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
Status: RO
Content-Length: 893

> It seems to me that the only Public interface that PHP exports from this
> dynamic object is the filename of the object.  The SONAME and all of its
> internal interfaces are strictly Private (Consolidation Private in the
> context of the PHP community, but Project Private in the context of Sun,
> via this project / ARC case).  The Public-ness here simply means that a
> customer can add the string "libphp5.so" to an Apache configuration file
> and expect that Apache will be able to load it as a module.  That sounds
> Committed to me -- when we decide to stop shipping any flavor of PHP5, then
> we go through an EOL process, which sounds reasonable.

The problem I see with Committed is that such an interface can only be
removed at major release intervals - given how infrequently we do that,
that seems too strong of a commitment level.

Have I misread the new taxnomy document?

dsc

From danek.duvall@sun.com Fri Apr  6 10:13:46 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36HDkJR022682
	for ; Fri, 6 Apr 2007 10:13:46 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l36HDDhN008408;
	Fri, 6 Apr 2007 10:13:13 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG300G016I0PV00@nwk-avmta-2.sfbay.sun.com>; Fri,
 06 Apr 2007 10:13:13 -0700 (PDT)
Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG300BWT6I0VM50@nwk-avmta-2.sfbay.sun.com>; Fri,
 06 Apr 2007 10:13:12 -0700 (PDT)
Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2)
 with ESMTP id l36HDCQs007515; Fri, 06 Apr 2007 10:13:12 -0700 (PDT)
Received: from zruty.sfbay.sun.com (localhost [127.0.0.1])
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l36H5ZR3023319; Fri,
 06 Apr 2007 10:05:35 -0700 (PDT)
Received: (from dduvall@localhost)
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l36H5YGw023318; Fri,
 06 Apr 2007 10:05:35 -0700 (PDT)
Date: Fri, 06 Apr 2007 10:05:34 -0700
From: Danek Duvall 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: 
To: David.Comay@sun.com
Cc: Stefan Teleman ,
        Bart Smaalders , psarc-ext@sun.com,
        Fred Thornborrow ,
        Joseph Kowalski 
Message-id: <20070406170534.GM1864@zruty.sfbay.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 
User-Agent: mutt-ng/devel-r535 (SunOS)
Status: RO
Content-Length: 480

On Fri, Apr 06, 2007 at 10:02:36AM -0700, David.Comay@sun.com wrote:

> The problem I see with Committed is that such an interface can only be
> removed at major release intervals - given how infrequently we do that,
> that seems too strong of a commitment level.
> 
> Have I misread the new taxnomy document?

We've always been able to remove Committed interfaces, but we have to go
through the EOL process, which seems entirely appropriate for this
particular interface.

Danek

From sommerfeld@sun.com Mon Apr  9 15:16:10 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39MGAH8006654
	for ; Mon, 9 Apr 2007 15:16:10 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l39MFVxB028987;
	Mon, 9 Apr 2007 15:15:33 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG900D0D4HXQ100@nwk-avmta-2.sfbay.sun.com>; Mon,
 09 Apr 2007 15:15:33 -0700 (PDT)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG900D764HWBJ00@nwk-avmta-2.sfbay.sun.com>; Mon,
 09 Apr 2007 15:15:32 -0700 (PDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l39MFQoZ008057; Mon, 09 Apr 2007 18:15:26 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39MFQoT022849; Mon,
 09 Apr 2007 18:15:26 -0400 (EDT)
Date: Mon, 09 Apr 2007 18:15:24 -0400
From: Bill Sommerfeld 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070406170534.GM1864@zruty.sfbay.sun.com>
To: Danek Duvall 
Cc: David.Comay@sun.com, Bart Smaalders , psarc-ext@sun.com,
        Joseph Kowalski ,
        Fred Thornborrow ,
        Stefan Teleman 
Message-id: <1176156924.21611.25.camel@thunk>
MIME-version: 1.0
X-Mailer: Evolution 2.8.1.1
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 
 <20070406170534.GM1864@zruty.sfbay.sun.com>
Status: RO
Content-Length: 385

On Fri, 2007-04-06 at 10:05 -0700, Danek Duvall wrote:
> > Have I misread the new taxnomy document?
> 
> We've always been able to remove Committed interfaces, but we have to go
> through the EOL process, which seems entirely appropriate for this
> particular interface.

Not EOL.  EOF.

(EOL is end of life for products.  EOF is end-of-feature for product
features).


						- Bill



From John.Plocher@sun.com Mon Apr  9 15:40:57 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39Meus9006976
	for ; Mon, 9 Apr 2007 15:40:56 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l39MeFN5008144;
	Tue, 10 Apr 2007 06:40:17 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG900E035N2WN00@nwk-avmta-2.sfbay.sun.com>; Mon,
 09 Apr 2007 15:40:14 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG900DJW5N1BG10@nwk-avmta-2.sfbay.sun.com>; Mon,
 09 Apr 2007 15:40:13 -0700 (PDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l39MeDpH021747; Mon,
 09 Apr 2007 15:40:13 -0700 (PDT)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JG900H015L5X900@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Mon,
 09 Apr 2007 15:40:13 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JG90013V5MYATI3@d1-sfbay-09.sun.com>; Mon,
 09 Apr 2007 15:40:11 -0700 (PDT)
Date: Mon, 09 Apr 2007 15:40:06 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070405222320.GI1864@zruty.sfbay.sun.com>
Sender: John.Plocher@sun.com
To: Danek Duvall 
Cc: Stefan Teleman ,
        Bart Smaalders , PSARC-EXT@sun.com,
        Fred Thornborrow ,
        David Comay , Joseph Kowalski 
Message-id: <461AC0C6.5030909@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 1747

Danek Duvall wrote:
> It seems to me that the only Public interface that PHP exports from this
> dynamic object is the filename of the object. 

> The dynamic object uses interfaces provided by Apache so that it can
> function as an Apache module.  These are the interfaces based on "unholy
> knowledge" as you and Joe are talking about.  These have some stability
> level that is defined by Apache, and not this project, and I don't think
> are really relevant for this case, and certainly wouldn't show up in any
> documentation related to this case, since we don't document a project's
> imported interfaces.

In other words, Apache defines a design pattern (or Interface) called
"the Apache Module API", which libphp5.so happens to implement.
Dozens and dozens of other extentions also implement that same
interface specification - it can't realistically change without
invalidating a large number of 3rd party apache modules.

This Apache Module interface definition is defacto Committed.  As
part of the Apache httpd consolidation, it can't change incompatibly
in micro or minor releases of the Apache httpd.

When configuring apache to use a DSO module like PHP5, one puts the
name of the  DSO file in an apache config file.  This is a public
interface that customers can rely on as various bugfixes and other
minor evolution of PHP happens (forcing people to edit their httpd.conf
after applying a patch seems bad...), so (IMHO) the SONAME needs to
be Committed as well.  The binding that requires a particular SONAME
would be to the Apache httpd consolidation/PHP distro and not to ON
or SFW - If a new and incompatible apache comes out, I certainly expect
that a new PHP module would also come out that would work with it...

   -John



From sommerfeld@sun.com Mon Apr  9 15:57:27 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39MvR0X007700
	for ; Mon, 9 Apr 2007 15:57:27 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l39MumCi042150;
	Mon, 9 Apr 2007 16:56:49 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG9003036EOPS00@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 09 Apr 2007 15:56:48 -0700 (PDT)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG900KKM6ENSAA0@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 09 Apr 2007 15:56:48 -0700 (PDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l39MujpB013427; Mon, 09 Apr 2007 18:56:45 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39MujHu023048; Mon,
 09 Apr 2007 18:56:45 -0400 (EDT)
Date: Mon, 09 Apr 2007 18:56:40 -0400
From: Bill Sommerfeld 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <461AC0C6.5030909@Sun.Com>
To: John Plocher 
Cc: Danek Duvall , Bart Smaalders ,
        Stefan Teleman ,
        Joseph Kowalski , PSARC-EXT@sun.com,
        Fred Thornborrow 
Message-id: <1176159401.22952.24.camel@thunk>
MIME-version: 1.0
X-Mailer: Evolution 2.8.1.1
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <461AC0C6.5030909@Sun.Com>
Status: RO
Content-Length: 662

On Mon, 2007-04-09 at 15:40 -0700, John Plocher wrote:
> In other words, Apache defines a design pattern (or Interface) called
> "the Apache Module API", which libphp5.so happens to implement.
> Dozens and dozens of other extentions also implement that same
> interface specification - it can't realistically change without
> invalidating a large number of 3rd party apache modules.

That conflicts with something we were told during the review of the
recent Apache case, which is that modules have to be built against a
specific version of apache.

Is it the case that there is a stable source-level module API but not an
stable module ABI?

						- Bill







From Stefan.Teleman@sun.com Mon Apr  9 16:01:14 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39N1EoN007717
	for ; Mon, 9 Apr 2007 16:01:14 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l39N0YNe002424;
	Mon, 9 Apr 2007 16:00:37 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG9004156L05200@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 09 Apr 2007 16:00:36 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.68.130])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG900M3F6L06X40@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 09 Apr 2007 16:00:36 -0700 (PDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39N0VnI191283; Mon,
 09 Apr 2007 16:00:31 -0700 (PDT)
Date: Mon, 09 Apr 2007 19:00:25 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <1176159401.22952.24.camel@thunk>
To: Bill Sommerfeld 
Cc: John Plocher , Danek Duvall ,
        Bart Smaalders , Joseph Kowalski ,
        PSARC-EXT@sun.com, Fred Thornborrow 
Reply-to: Stefan Teleman 
Message-id: <461AC589.3060702@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <461AC0C6.5030909@Sun.Com> <1176159401.22952.24.camel@thunk>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 739

Bill Sommerfeld wrote:
> On Mon, 2007-04-09 at 15:40 -0700, John Plocher wrote:
>> In other words, Apache defines a design pattern (or Interface) called
>> "the Apache Module API", which libphp5.so happens to implement.
>> Dozens and dozens of other extentions also implement that same
>> interface specification - it can't realistically change without
>> invalidating a large number of 3rd party apache modules.
> 
> That conflicts with something we were told during the review of the
> recent Apache case, which is that modules have to be built against a
> specific version of apache.

It does not conflict. This is exactly what the Apache ARC Case explained.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From danek.duvall@sun.com Mon Apr  9 16:11:53 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39NBqeY008223
	for ; Mon, 9 Apr 2007 16:11:52 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l39NBB8E028764;
	Tue, 10 Apr 2007 00:11:13 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG90040372OC300@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:11:12 -0600 (MDT)
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG90036F72NQ400@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:11:12 -0600 (MDT)
Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40])
	by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l39NBBij028647; Mon, 09 Apr 2007 16:11:11 -0700 (PDT)
Received: from zruty.sfbay.sun.com (localhost [127.0.0.1])
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l39N3Yfp008133; Mon,
 09 Apr 2007 16:03:34 -0700 (PDT)
Received: (from dduvall@localhost)
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l39N3YQS008132; Mon,
 09 Apr 2007 16:03:34 -0700 (PDT)
Date: Mon, 09 Apr 2007 16:03:34 -0700
From: Danek Duvall 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <46158450.7080908@Sun.COM>
To: Stefan Teleman 
Cc: Joseph Kowalski , Bill Sommerfeld ,
        David Comay , Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <20070409230334.GY1864@zruty.sfbay.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <46158450.7080908@Sun.COM>
User-Agent: mutt-ng/devel-r535 (SunOS)
Status: RO
Content-Length: 2676

On Thu, Apr 05, 2007 at 07:20:48PM -0400, Stefan Teleman wrote:

> >It seems to me that the only Public interface that PHP exports from this
> >dynamic object is the filename of the object. 
> 
> Plus the required glue to make libphp5.so identify itself to Apache as an 
> Apache Module [which is done at PHP ./configure time].

That glue, as John puts more precisely than I did, is the implementation of
the Apache module interface.  That is, PHP here is doing what Apache
requires of it, not the other way around.

> Yes it does. I think we're down to reconciling the following set of 
> constraints:
> 
> 0. libphp5.so's Exported Interfaces are, in fact, Project Private.

Most of them.  Like I said, the module's filename is not.

> 1. libphp5.so is an integral component of an Integration which tries to be 
> Uncommitted, because Volatile or Project Private would allow for the removal of 
> this object, or for the binary incompatible update of this object. This 
> integration wants a stronger Stability Level.

Integrations don't have stability levels.  Interfaces do.  You're going to
need to be more precise about which interfaces you want to be at what
levels.  I'll offer my original suggestion again -- the apache module name
is Committed, the PHP language and libraries are Volatile, and everything
else is Project Private.

> 2. Apache has a hard dependency on libphp5.so's Exported Interfaces, because it 
> may want to load it as an Apache Module.

Again, you have that backwards.

> 3. PHP has a hard dependency on Apache's Exported Interfaces.

That's the statement that your #2 should be.

> The weird contradiction in all this is that, Apache doesn't need a Contract 
> from PHP,

Correct -- Apache doesn't depend on PHP.

> It's PHP  who needs a contract from Apache, because PHP is bound to the
> Interfaces exported by Apache at the time PHP was ./configure'd. Apache
> needs to promise PHP that it won't change.

That promise may already come from the commitment level of those
interfaces, but I don't know what they are offhand.  You say Uncommitted,
but apply it to all of Apache, which is far too coarse to make this
determination.

> But, if we make PHP Volatile or Project Private, it can't ask for a
> Contract from an API which has a stronger (higher) Stability Level

Why not?

It would make sense at some level to make sure that all Apache modules we
deliver have a contract with the Apache case to make sure they're notified
when Apache is upgraded to a version that changes the module ABI.  Whether
anyone thinks that's actually worthwhile, I dunno, but it would be standard
procedure for Sun-internal projects of a similar nature.

Danek

From danek.duvall@sun.com Mon Apr  9 16:32:26 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39NWPI8008860
	for ; Mon, 9 Apr 2007 16:32:25 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l39NVeU1002406;
	Tue, 10 Apr 2007 00:31:46 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG90060580WHP00@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:31:44 -0600 (MDT)
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG90036080VPE10@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:31:43 -0600 (MDT)
Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40])
	by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l39NVhnu006322; Mon, 09 Apr 2007 16:31:43 -0700 (PDT)
Received: from zruty.sfbay.sun.com (localhost [127.0.0.1])
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l39Ms8NZ008058; Mon,
 09 Apr 2007 15:54:08 -0700 (PDT)
Received: (from dduvall@localhost)
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l39Ms8Nv008057; Mon,
 09 Apr 2007 15:54:08 -0700 (PDT)
Date: Mon, 09 Apr 2007 15:54:07 -0700
From: Danek Duvall 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <461AC0C6.5030909@Sun.Com>
To: John Plocher 
Cc: Stefan Teleman ,
        Bart Smaalders , PSARC-EXT@sun.com,
        Fred Thornborrow ,
        David Comay , Joseph Kowalski 
Message-id: <20070409225407.GX1864@zruty.sfbay.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <461AC0C6.5030909@Sun.Com>
User-Agent: mutt-ng/devel-r535 (SunOS)
Status: RO
Content-Length: 1128

On Mon, Apr 09, 2007 at 03:40:06PM -0700, John Plocher wrote:

> This Apache Module interface definition is defacto Committed.  As
> part of the Apache httpd consolidation, it can't change incompatibly
> in micro or minor releases of the Apache httpd.

Except that, as I understand it, it *does* change on dot-releases (from 2.0
to 2.2).  Which I guess makes those Major releases according to Sun's
taxonomy document.

> When configuring apache to use a DSO module like PHP5, one puts the
> name of the  DSO file in an apache config file.  This is a public
> interface that customers can rely on as various bugfixes and other
> minor evolution of PHP happens (forcing people to edit their httpd.conf
> after applying a patch seems bad...), so (IMHO) the SONAME needs to
> be Committed as well.

I'm not sure I follow that last leap.  Given that the module is dlopened by
apache, and not linked to it via its DT_NEEDED section, why does the SONAME
matter at all?

> If a new and incompatible apache comes out, I certainly expect that a new
> PHP module would also come out that would work with it...

I'd agree with that.

Danek

From Stefan.Teleman@sun.com Mon Apr  9 16:32:51 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39NWon0008872
	for ; Mon, 9 Apr 2007 16:32:50 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l39NVnxX002439;
	Tue, 10 Apr 2007 00:32:10 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG90060581JIS00@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:32:07 -0600 (MDT)
Received: from jurassic.eng.sun.com ([129.146.58.166])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG90034O81IPW10@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:32:07 -0600 (MDT)
Received: from [192.9.61.113]
 (punchin-client-192-9-61-113.SFBay.Sun.COM [192.9.61.113])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39NW55p200154; Mon,
 09 Apr 2007 16:32:05 -0700 (PDT)
Date: Mon, 09 Apr 2007 19:31:59 -0400
From: Stefan Teleman 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070409230334.GY1864@zruty.sfbay.sun.com>
To: Danek Duvall 
Cc: Joseph Kowalski , Bill Sommerfeld ,
        David Comay , Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Reply-to: Stefan Teleman 
Message-id: <461ACCEF.4020601@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <46158450.7080908@Sun.COM> <20070409230334.GY1864@zruty.sfbay.sun.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 2622



Danek Duvall wrote:

>> 2. Apache has a hard dependency on libphp5.so's Exported Interfaces, because it 
>> may want to load it as an Apache Module.
> 
> Again, you have that backwards.

No, i don't. Apache version 2.2.4 can only load a PHP library built against 
Apache 2.2.4, with the same mpm, and the same APR Interface. It cannot load a 
PHP built with a different Apache, or a different MPM, or a different APR 
Interface. PHP's Exported Interfaces are dependent on how PHP was ./configure'd 
and built, and this, in turn, depends on which particular version of Apache was 
used by PHP at ./configure time. More precisely, PHP depends on a particular 
version of APXS. Therefore, the moment libphp5.so comes into existence, Apache 
depends on this libphp5.so exporting a set of Interfaces which are compatible 
with the Interfaces expected by Apache. More precisely, Apache expects 
libphp5.so to export its interfaces according to the configuration parameters 
dictated by the appropriate APXS.

>> 3. PHP has a hard dependency on Apache's Exported Interfaces.
> 
> That's the statement that your #2 should be.

No. Statement #2 is a precursor to statement #3.

>> The weird contradiction in all this is that, Apache doesn't need a Contract 
>> from PHP,
> 
> Correct -- Apache doesn't depend on PHP.

Apache does not depend on PHP *if and only if* Apache never loads PHP. That is 
not the case being discussed here. The case being discussed here is the case of 
the dependencies between Apache and PHP because Apache wants to load PHP, and 
PHP was configured against a certain Apache. For any given version of Apache, it 
does not care that there may be several versions of PHP built against the same 
APXS, and that any one of them is loadable. However, there is an implicit hard 
dependency between this version of Apache, and any of the versions of PHP 
available, built against this Apache.

>> It's PHP  who needs a contract from Apache, because PHP is bound to the
>> Interfaces exported by Apache at the time PHP was ./configure'd. Apache
>> needs to promise PHP that it won't change.
> 
> That promise may already come from the commitment level of those
> interfaces, but I don't know what they are offhand.  You say Uncommitted,
> but apply it to all of Apache, which is far too coarse to make this
> determination.
> 
>> But, if we make PHP Volatile or Project Private, it can't ask for a
>> Contract from an API which has a stronger (higher) Stability Level
> 
> Why not?

Because of the hard dependencies explained above.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jek3@sun.com Mon Apr  9 16:56:41 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39NueoB009443
	for ; Mon, 9 Apr 2007 16:56:41 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l39Ntr6g026918;
	Tue, 10 Apr 2007 07:56:00 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG900I0195ASM00@nwk-avmta-2.sfbay.sun.com>; Mon,
 09 Apr 2007 16:55:58 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG900D86959BG50@nwk-avmta-2.sfbay.sun.com>; Mon,
 09 Apr 2007 16:55:57 -0700 (PDT)
Received: from [129.150.12.53]
 (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])	by
 jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l39NttRU315387;
 Mon, 09 Apr 2007 16:55:56 -0700 (PDT)
Date: Mon, 09 Apr 2007 13:55:12 -1000
From: Joseph Kowalski 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <20070409225407.GX1864@zruty.sfbay.sun.com>
To: Danek Duvall 
Cc: John Plocher ,
        Stefan Teleman ,
        Bart Smaalders , PSARC-EXT@sun.com,
        Fred Thornborrow ,
        David Comay 
Message-id: <461AD260.40207@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM>
 <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <461AC0C6.5030909@Sun.Com> <20070409225407.GX1864@zruty.sfbay.sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 451

Danek Duvall wrote:
> I'm not sure I follow that last leap.  Given that the module is dlopened by
> apache, and not linked to it via its DT_NEEDED section, why does the SONAME
> matter at all?
>   
If turns out it doesn't (it just took me a few days to understand that).

The discussion is now (as I believe it) just how to classify the library 
name (which
is dlopened) and the contents of the library (the entry points which are 
dlsym'd).

- jek3


From John.Plocher@sun.com Mon Apr  9 16:56:50 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l39NunvG009455
	for ; Mon, 9 Apr 2007 16:56:49 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l39Nu7Sm007222;
	Tue, 10 Apr 2007 00:56:10 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG90090195L2N00@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:56:09 -0600 (MDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.5])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG90037N95KPG20@brm-avmta-1.central.sun.com>; Mon,
 09 Apr 2007 17:56:08 -0600 (MDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l39Nu8pc011522; Mon,
 09 Apr 2007 16:56:08 -0700 (PDT)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JG900M01959G700@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Mon,
 09 Apr 2007 16:56:08 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JG9001QI95JAUD2@d1-sfbay-09.sun.com>; Mon,
 09 Apr 2007 16:56:07 -0700 (PDT)
Date: Mon, 09 Apr 2007 16:56:03 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <1176159401.22952.24.camel@thunk>
Sender: John.Plocher@sun.com
To: Bill Sommerfeld 
Cc: Danek Duvall , Bart Smaalders ,
        Stefan Teleman ,
        Joseph Kowalski , PSARC-EXT@sun.com,
        Fred Thornborrow 
Message-id: <461AD293.7010606@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <461AC0C6.5030909@Sun.Com> <1176159401.22952.24.camel@thunk>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 1243

Bill Sommerfeld wrote:
> Is it the case that there is a stable source-level module API but not an
> stable module ABI?

On looking into this further, it may be more the former; the granularity
seems to be at the 1.3/2.0/2.2 level, BUT N.B. Stefan's comments re:
build-time .configure dependencies.

Danek Duvall wrote:
> Except that, as I understand it, it *does* change on dot-releases (from 2.0
> to 2.2).  Which I guess makes those Major releases according to Sun's
> taxonomy document.


Don't become confused by trying to map Sun's Major.Minor.Micro release
taxonomy syntax onto Apache's release numbers!  As you say, both
2.0 and 2.2 were "major" releases.

> I'm not sure I follow that last leap.  Given that the module is dlopened by
> apache, and not linked to it via its DT_NEEDED section, why does the SONAME
> matter at all?

You are right in that the SONAME is not encoded in apache's httpd binary,
but it /is/ encoded in its httpd.conf file.  If that name changes (and
if the httpd.conf file is not changed to match), the web server environment
stops working.

 From a "API + documentation = Public" perspective, this whole module linkage
by editing httpd.conf sure smells like a public Committed interface set to me.

   -John


From danek.duvall@sun.com Mon Apr  9 17:22:38 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3A0MbAx010004
	for ; Mon, 9 Apr 2007 17:22:38 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3A0LwDL011817;
	Tue, 10 Apr 2007 01:21:59 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JG900901ACMYR00@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 09 Apr 2007 17:21:58 -0700 (PDT)
Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JG900MPNACF6Z60@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 09 Apr 2007 17:21:51 -0700 (PDT)
Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2)
 with ESMTP id l3A0LpVK005688; Mon, 09 Apr 2007 17:21:51 -0700 (PDT)
Received: from zruty.sfbay.sun.com (localhost [127.0.0.1])
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l39NpjG2008545; Mon,
 09 Apr 2007 16:51:45 -0700 (PDT)
Received: (from dduvall@localhost)
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l39NpjJW008544; Mon,
 09 Apr 2007 16:51:45 -0700 (PDT)
Date: Mon, 09 Apr 2007 16:51:43 -0700
From: Danek Duvall 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <461ACCEF.4020601@Sun.COM>
To: Stefan Teleman 
Cc: Joseph Kowalski , Bill Sommerfeld ,
        David Comay , Bart Smaalders ,
        Fred Thornborrow , PSARC-EXT@sun.com
Message-id: <20070409235143.GA1864@zruty.sfbay.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM>
 <46156880.7020008@sun.com> <46156D1B.6070405@Sun.COM>
 <46157040.6040002@sun.com> <461571E1.6080201@Sun.COM>
 <20070405222320.GI1864@zruty.sfbay.sun.com> <46158450.7080908@Sun.COM>
 <20070409230334.GY1864@zruty.sfbay.sun.com> <461ACCEF.4020601@Sun.COM>
User-Agent: mutt-ng/devel-r535 (SunOS)
Status: RO
Content-Length: 1257

On Mon, Apr 09, 2007 at 07:31:59PM -0400, Stefan Teleman wrote:

> Danek Duvall wrote:
> 
> >>2. Apache has a hard dependency on libphp5.so's Exported Interfaces, because 
> >>it may want to load it as an Apache Module.
> >Again, you have that backwards.
> 
> No, i don't. Apache version 2.2.4 can only load a PHP library built against 
> Apache 2.2.4, with the same mpm, and the same APR Interface.

Ah, I see what you mean.  That may be true, but in ARC terminology, Apache
defines the interfaces and PHP consumes those definitions.  Neither which
program is in charge of executing the code nor which module contains the
code being run is relevant; the argument is purely architectural.

> >>But, if we make PHP Volatile or Project Private, it can't ask for a
> >>Contract from an API which has a stronger (higher) Stability Level
> >Why not?
> 
> Because of the hard dependencies explained above.

As I read it, your statement is purely a taxonomic one -- that one project
can't get a contract from another project if contract involves an interface
from the latter project at a higher stability level than an interface from
the former project.  That statement is wrong.  And I'm not sure how else to
read the statement as you actually phrased it.

Danek

From sommerfeld@sun.com Tue Apr 10 14:28:05 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3ALS5F9006201
	for ; Tue, 10 Apr 2007 14:28:05 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3ALRROX022328;
	Tue, 10 Apr 2007 14:27:28 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JGA00K13WXR7P00@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 10 Apr 2007 14:27:27 -0700 (PDT)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JGA006B2WXNTUD0@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 10 Apr 2007 14:27:24 -0700 (PDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
 with ESMTP id l3ALRLg2005574; Tue, 10 Apr 2007 17:27:21 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3ALRLVS026266; Tue,
 10 Apr 2007 17:27:21 -0400 (EDT)
Date: Tue, 10 Apr 2007 17:27:19 -0400
From: Bill Sommerfeld 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <461AD293.7010606@Sun.Com>
To: John Plocher 
Cc: Danek Duvall , Bart Smaalders ,
        Stefan Teleman ,
        Joseph Kowalski , PSARC-EXT@sun.com,
        Fred Thornborrow 
Message-id: <1176240439.22952.150.camel@thunk>
MIME-version: 1.0
X-Mailer: Evolution 2.8.1.1
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <461AC0C6.5030909@Sun.Com> <1176159401.22952.24.camel@thunk>
 <461AD293.7010606@Sun.Com>
Status: RO
Content-Length: 540

On Mon, 2007-04-09 at 16:56 -0700, John Plocher wrote:
>  From a "API + documentation = Public" perspective, this whole module linkage
> by editing httpd.conf sure smells like a public Committed interface set to me.

Yes, the sequence of tokens which lands in the httpd.conf file sounds
like a Committed interface.  

But since it's simply telling apache to go off and dlopen a file, we
need to tread carefully to avoid creating the impression that the *ABI*
between apache and the modules is Committed or even Uncommitted.

					- Bill




From danek.duvall@sun.com Tue Apr 10 15:07:42 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3AM7fAP008513
	for ; Tue, 10 Apr 2007 15:07:42 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3AM6wSh016443;
	Wed, 11 Apr 2007 06:07:02 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JGA00M17YRNZD00@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 10 Apr 2007 15:06:59 -0700 (PDT)
Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JGA00MTTYRJ0P00@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 10 Apr 2007 15:06:56 -0700 (PDT)
Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2)
 with ESMTP id l3AM6te6023348; Tue, 10 Apr 2007 15:06:55 -0700 (PDT)
Received: from zruty.sfbay.sun.com (localhost [127.0.0.1])
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3ALanGW015390; Tue,
 10 Apr 2007 14:36:49 -0700 (PDT)
Received: (from dduvall@localhost)
	by zruty.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l3ALanui015389; Tue,
 10 Apr 2007 14:36:49 -0700 (PDT)
Date: Tue, 10 Apr 2007 14:36:49 -0700
From: Danek Duvall 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <461AD293.7010606@Sun.Com>
To: John Plocher 
Cc: Bill Sommerfeld , Bart Smaalders ,
        Stefan Teleman ,
        Joseph Kowalski , PSARC-EXT@sun.com,
        Fred Thornborrow 
Message-id: <20070410213649.GE1864@zruty.sfbay.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <46154335.90702@sun.com> <46154BB4.7070603@Sun.COM>
 <46156880.7020008@sun.com> <46156D1B.6070405@Sun.COM>
 <46157040.6040002@sun.com> <461571E1.6080201@Sun.COM>
 <20070405222320.GI1864@zruty.sfbay.sun.com> <461AC0C6.5030909@Sun.Com>
 <1176159401.22952.24.camel@thunk> <461AD293.7010606@Sun.Com>
User-Agent: mutt-ng/devel-r535 (SunOS)
Status: RO
Content-Length: 470

On Mon, Apr 09, 2007 at 04:56:03PM -0700, John Plocher wrote:

> You are right in that the SONAME is not encoded in apache's httpd binary,
> but it /is/ encoded in its httpd.conf file.

No, the SONAME of the shared object isn't encoded anywhere except the
module's ELF section.  The *filename* of the shared object is encoded in
the httpd.conf file.  The fact that the SONAME and the filename of the
shared object are the same is, AFAIK, completely coincidental.

Danek

From John.Plocher@sun.com Tue Apr 10 15:16:40 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3AMGdqR008734
	for ; Tue, 10 Apr 2007 15:16:39 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3AMG0Hb020681;
	Tue, 10 Apr 2007 23:16:01 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JGA00H03Z6M9W00@nwk-avmta-2.sfbay.sun.com>; Tue,
 10 Apr 2007 15:15:58 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JGA00DWRZ6MZG30@nwk-avmta-2.sfbay.sun.com>; Tue,
 10 Apr 2007 15:15:58 -0700 (PDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3AMFweh025495; Tue,
 10 Apr 2007 15:15:58 -0700 (PDT)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JGA00B01Z4D0100@d1-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Tue,
 10 Apr 2007 15:15:58 -0700 (PDT)
Received: from [129.146.58.87] by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JGA001TSZ6GATQB@d1-sfbay-09.sun.com>; Tue,
 10 Apr 2007 15:15:52 -0700 (PDT)
Date: Tue, 10 Apr 2007 15:15:48 -0700
From: John Plocher 
Subject: Re: PSARC/2007/168 Including PHP5 with Solaris
In-reply-to: <1176240439.22952.150.camel@thunk>
Sender: John.Plocher@sun.com
To: Bill Sommerfeld 
Cc: Danek Duvall , Bart Smaalders ,
        Stefan Teleman ,
        Joseph Kowalski , PSARC-EXT@sun.com,
        Fred Thornborrow 
Message-id: <461C0C94.4070203@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <4613F286.6010506@sun.com> <46140351.5070405@Sun.COM>
 <46141E07.30808@sun.com> <46152C20.4040204@Sun.COM> <46154335.90702@sun.com>
 <46154BB4.7070603@Sun.COM> <46156880.7020008@sun.com>
 <46156D1B.6070405@Sun.COM> <46157040.6040002@sun.com>
 <461571E1.6080201@Sun.COM> <20070405222320.GI1864@zruty.sfbay.sun.com>
 <461AC0C6.5030909@Sun.Com> <1176159401.22952.24.camel@thunk>
 <461AD293.7010606@Sun.Com> <1176240439.22952.150.camel@thunk>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Status: RO
Content-Length: 441

Bill Sommerfeld wrote:
> But since it's simply telling apache to go off and dlopen a file, we
> need to tread carefully to avoid creating the impression that the *ABI*
> between apache and the modules is Committed or even Uncommitted.

If (as Stefan says) the ABI is compile-time dependent on the apache
httpd server's build environment, then the only public classification
that makes sense here seems to be "Contracted Volatile".

   -John

From sacadmin Wed Apr 25 09:24:24 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3PGON4W004853
	for ; Wed, 25 Apr 2007 09:24:24 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3PGNUdf042576;
	Wed, 25 Apr 2007 10:23:33 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JH200J13AV8A600@nwk-avmta-2.sfbay.sun.com>; Wed,
 25 Apr 2007 09:23:32 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JH200ER4AV731A0@nwk-avmta-2.sfbay.sun.com>; Wed,
 25 Apr 2007 09:23:31 -0700 (PDT)
Received: from d1-sfbay-10.sun.com ([192.18.39.120])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3PGNVaY015131; Wed,
 25 Apr 2007 09:23:31 -0700 (PDT)
Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JH200401AQLJV00@d1-sfbay-10.sun.com>
 (original mail from Sherri.Shieh@Sun.COM); Wed,
 25 Apr 2007 09:23:31 -0700 (PDT)
Received: from [129.145.154.103] by d1-sfbay-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JH200M5LAV7D77G@d1-sfbay-10.sun.com>; Wed,
 25 Apr 2007 09:23:31 -0700 (PDT)
Date: Wed, 25 Apr 2007 09:23:30 -0700
From: Sherri Shieh 
Subject: PSARC Fast Track: Including PHP5 with Solaris (2007/168)
Sender: Sherri.Shieh@Sun.COM
To: psarc@Sun.COM, Bart Smaalders 
Cc: Stefan.Teleman@Sun.COM
Message-id: <462F8082.3060500@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
X-PMX-Version: 5.2.0.264296
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060120
Status: RO
Content-Length: 357

I have marked this case closed approved as it was approved during PSARC 
two weeks ago.

- Sherri

-- 


=========================================================
Sherri Shieh			Sun Microsystems, Inc.
Program Manager			Email: sherri.shieh@sun.com
Systems Architecture		Phone: 650-786-5245/x85245
===========================================================


From Stefan.Teleman@sun.com Mon Aug 13 10:06:30 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7DH6Ur9017389
	for ; Mon, 13 Aug 2007 10:06:30 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7DH41Tn021820;
	Mon, 13 Aug 2007 10:04:04 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JMQ0082B22S2J00@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 13 Aug 2007 10:04:04 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.106.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JMQ0056K22Q3VE0@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 13 Aug 2007 10:04:03 -0700 (PDT)
Received: from [10.7.250.12]
 (punchin-client-10-7-250-12.SFBay.Sun.COM [10.7.250.12])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7DH42AM370220; Mon,
 13 Aug 2007 10:04:02 -0700 (PDT)
Date: Mon, 13 Aug 2007 13:01:59 -0400
From: Stefan Teleman 
Subject: PSARC/2007/168 Including PHP5 with Solaris
To: PSARC-EXT@sun.com, David Comay ,
        Fred Thornborrow ,
        Murthy Chintalapati ,
        Georgina Chua 
Reply-to: Stefan Teleman 
Message-id: <46C08E87.9040602@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
Status: RO
Content-Length: 857

Hi.

I would like to amend PSARC/2007/168 [Including PHP5 with Solaris] as follows:

Since PSARC/2007/168 was approved, the PHP Group has released PHP5 Version 
5.2.3. This release of PHP5 contains numerous and significant bug fixes:

http://www.php.net/ChangeLog-5.php#5.2.3

which includes *very important* security/bug fixes.

PHP 5.2.3 is the current PHP5 Stable Release.

No Interface changes are provided by PHP 5.2.3, compared to PHP 5.2.0 (which was 
originally approved). PHP 5.2.3 is only a bug fix release.

No license changes are provided by PHP 5.2.3 (compared to PHP 5.2.0):

http://www.php.net/license/

Please let me know if this email is sufficient for an ARC Case Amendment (PHP5 
Micro Version Upgrade), or if a new FastTrack is required.

Thank you very much.

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jyri@buye.red.iplanet.com Tue Sep 11 12:55:52 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BJtqPc004344
	for ; Tue, 11 Sep 2007 12:55:52 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BJqMng015669;
	Tue, 11 Sep 2007 13:52:24 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JO70040PZ8EQ200@nwk-avmta-2.sfbay.sun.com>; Tue,
 11 Sep 2007 12:53:02 -0700 (PDT)
Received: from buye.red.iplanet.com ([192.18.65.224])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JO700LX8Z8D5G90@nwk-avmta-2.sfbay.sun.com>; Tue,
 11 Sep 2007 12:53:01 -0700 (PDT)
Received: from buye.red.iplanet.com (localhost [127.0.0.1])
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id l8BJjW9q004726; Tue,
 11 Sep 2007 12:45:32 -0700 (PDT)
Received: (from jyri@localhost)
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id l8BJjWD3004725; Tue,
 11 Sep 2007 12:45:32 -0700 (PDT)
Date: Tue, 11 Sep 2007 12:45:32 -0700
From: Jyri Virkki 
Subject: Inconsistencies in PSARC/2007/168 materials
To: psarc-ext@sun.com, webstack-discuss@opensolaris.org,
        Stefan.Teleman@sun.com
Message-id: <20070911194532.GI4545@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
User-Agent: Mutt/1.5.11
Status: RO
Content-Length: 1415


Turns out there are some inconsistencies in the file layout between
http://www.opensolaris.org/os/community/arc/caselog/2007/168/materials/php5filestructure-txt/
and the main specification, 
http://www.opensolaris.org/os/community/arc/caselog/2007/168/materials/php5fasttrack-txt/

The file layout addendum document (php5filestructure-txt) contains a
number of soft links both inside the /usr/php5/ area such as

        /usr/php5/bin/ -> /usr/php5/[version]/bin/
        /usr/php5/include/ -> /usr/php5/[version]/include/

and so forth, as well as elsewhere such as

        /usr/bin/php -> /usr/php5/[version]/bin/php
        /usr/bin/php-config -> /usr/php5/[version]/bin/php-config
        /usr/bin/phpize -> /usr/php5/[version]/bin/phpize

During the discussion
http://www.opensolaris.org/os/community/arc/caselog/2007/168/mail
these soft links were removed and they were removed from the
functional specification.

It looks like only the functional specification document was updated
(a few times) during the case discussion. The other files were
never modified from the time they were submitted and thus fell behind.
(Another example of why never to duplicate info in more than one doc...)

Here are the timestamps on the files as of today:

    22770 Mar 28 19:27 PHP5FastTrack.txt
     9467 Feb 27  2007 PHP5FileStructure.txt
     3266 Feb 23  2007 PHP5Man1Page.txt
     8902 Feb 23  2007 PHP5ManPage.txt

From this, it seems clear to me that PHP5FastTrack.txt
Status: RO

(php5filestructure-txt) contains the case as approved and the
PHP5FileStructure.txt (php5filestructure-txt) is no longer valid.

Stefan, can you confirm this?



-- 
Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems

From Stefan.Teleman@Sun.COM Tue Sep 11 13:00:52 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BK0pAX004789
	for ; Tue, 11 Sep 2007 13:00:51 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BJvxYg015979;
	Tue, 11 Sep 2007 20:58:00 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JO700H17ZGNE600@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 11 Sep 2007 12:57:59 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.58.37])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JO700FHRZGJOZ10@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 11 Sep 2007 12:57:55 -0700 (PDT)
Received: from [10.7.250.25]
 (punchin-client-10-7-250-25.SFBay.Sun.COM [10.7.250.25])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BJvskA284090; Tue,
 11 Sep 2007 12:57:55 -0700 (PDT)
Date: Tue, 11 Sep 2007 15:56:59 -0400
From: Stefan Teleman 
Subject: Re: Inconsistencies in PSARC/2007/168 materials
In-reply-to: <20070911194532.GI4545@sun.com>
To: Jyri Virkki 
Cc: psarc-ext@Sun.COM, webstack-discuss@opensolaris.org
Reply-to: Stefan Teleman 
Message-id: <46E6F30B.2050306@Sun.COM>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <20070911194532.GI4545@sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070802)
Status: RO
Content-Length: 1872

In which document do you see the symlinks removed ?

--Stefan

-----

Jyri Virkki wrote:
> Turns out there are some inconsistencies in the file layout between
> http://www.opensolaris.org/os/community/arc/caselog/2007/168/materials/php5filestructure-txt/
> and the main specification, 
> http://www.opensolaris.org/os/community/arc/caselog/2007/168/materials/php5fasttrack-txt/
> 
> The file layout addendum document (php5filestructure-txt) contains a
> number of soft links both inside the /usr/php5/ area such as
> 
>         /usr/php5/bin/ -> /usr/php5/[version]/bin/
>         /usr/php5/include/ -> /usr/php5/[version]/include/
> 
> and so forth, as well as elsewhere such as
> 
>         /usr/bin/php -> /usr/php5/[version]/bin/php
>         /usr/bin/php-config -> /usr/php5/[version]/bin/php-config
>         /usr/bin/phpize -> /usr/php5/[version]/bin/phpize
> 
> During the discussion
> http://www.opensolaris.org/os/community/arc/caselog/2007/168/mail
> these soft links were removed and they were removed from the
> functional specification.
> 
> It looks like only the functional specification document was updated
> (a few times) during the case discussion. The other files were
> never modified from the time they were submitted and thus fell behind.
> (Another example of why never to duplicate info in more than one doc...)
> 
> Here are the timestamps on the files as of today:
> 
>     22770 Mar 28 19:27 PHP5FastTrack.txt
>      9467 Feb 27  2007 PHP5FileStructure.txt
>      3266 Feb 23  2007 PHP5Man1Page.txt
>      8902 Feb 23  2007 PHP5ManPage.txt
> 
> From this, it seems clear to me that PHP5FastTrack.txt
> (php5filestructure-txt) contains the case as approved and the
> PHP5FileStructure.txt (php5filestructure-txt) is no longer valid.
> 
> Stefan, can you confirm this?
> 
> 
> 

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman@Sun.COM


From jyri@buye.red.iplanet.com Tue Sep 11 13:28:37 2007
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BKSbZs005134
	for ; Tue, 11 Sep 2007 13:28:37 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BKP8o0027191;
	Tue, 11 Sep 2007 14:25:09 -0600 (MDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JO80001N0QZAA00@brm-avmta-1.central.sun.com>; Tue,
 11 Sep 2007 14:25:47 -0600 (MDT)
Received: from buye.red.iplanet.com ([192.18.65.224])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JO800IJ50QXQK60@brm-avmta-1.central.sun.com>; Tue,
 11 Sep 2007 14:25:46 -0600 (MDT)
Received: from buye.red.iplanet.com (localhost [127.0.0.1])
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id l8BKIFUg004776; Tue,
 11 Sep 2007 13:18:15 -0700 (PDT)
Received: (from jyri@localhost)
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id l8BKIF9p004775; Tue,
 11 Sep 2007 13:18:15 -0700 (PDT)
Date: Tue, 11 Sep 2007 13:18:15 -0700
From: Jyri Virkki 
Subject: Re: [webstack-discuss] Inconsistencies in PSARC/2007/168 materials
In-reply-to: <46E6F30B.2050306@Sun.COM>
To: Stefan Teleman 
Cc: psarc-ext@sun.com, webstack-discuss@opensolaris.org
Message-id: <20070911201815.GJ4545@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <20070911194532.GI4545@sun.com> <46E6F30B.2050306@Sun.COM>
User-Agent: Mutt/1.5.11
Status: RO
Content-Length: 327

Stefan Teleman wrote:
>
> In which document do you see the symlinks removed ?


The links were removed from PHP5FastTrack.txt between the copy sent
out on March 20 and the one sent out on April 4 (both revisions are in
the case email logs, URL in previous email).



-- 
Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems

From Sriram.Natarajan@sun.com Thu Sep 13 13:08:41 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8DK8egQ007853
	for ; Thu, 13 Sep 2007 13:08:40 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l8DK5fZJ028766
	for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 14 Sep 2007 04:05:47 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JOB00501P5KL200@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com
 (ORCPT psarc-ext@sun.com); Thu, 13 Sep 2007 13:05:44 -0700 (PDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JOB000PKP5KFSB0@nwk-avmta-2.sfbay.sun.com> for
 psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu,
 13 Sep 2007 13:05:44 -0700 (PDT)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8DK5i2B012255	for
 ; Thu, 13 Sep 2007 20:05:44 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JOB00I01NBO2400@mail-amer.sun.com>
 (original mail from Sriram.Natarajan@Sun.COM)
 for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu,
 13 Sep 2007 14:05:44 -0600 (MDT)
Received: from [192.18.120.213] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JOB00L4JP50AMD0@mail-amer.sun.com>; Thu,
 13 Sep 2007 14:05:24 -0600 (MDT)
Date: Thu, 13 Sep 2007 13:03:53 -0700
From: Sriram Natarajan 
Subject: Re: [webstack-discuss] Inconsistencies in PSARC/2007/168 materials
In-reply-to: <20070911201815.GJ4545@sun.com>
Sender: Sriram.Natarajan@sun.com
To: Jyri Virkki 
Cc: Stefan Teleman , psarc-ext@sun.com,
        webstack-discuss@opensolaris.org
Message-id: <46E997A9.6070907@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <20070911194532.GI4545@sun.com> <46E6F30B.2050306@Sun.COM>
 <20070911201815.GJ4545@sun.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
Status: RO
Content-Length: 354

Is there any update on this thread ?

Jyri Virkki wrote:
> Stefan Teleman wrote:
>   
>> In which document do you see the symlinks removed ?
>>     
>
>
> The links were removed from PHP5FastTrack.txt between the copy sent
> out on March 20 and the one sent out on April 4 (both revisions are in
> the case email logs, URL in previous email).
>
>
>
>