Nick Thanks for responding. Please see my response inline - Sriram
Nick Kew wrote: > > On 9 Jul 2008, at 04:02, Sriram Natarajan wrote: > >> Hi >> I am currently working towards PHP 5.2.6 integration and as part of >> this work I am working towards refactoring our PHP package to make it >> simpler and easier to maintain. The reasoning being that micro releases >> within PHP tend to retain backward compatibility and hence we would like >> to remove the 'micro' release version information within our package >> names and file layout. At the same time, we do want to the ability to >> carry multiple versions (either minor or major releases) . For >> example, customers using OpenSolaris should still be able to install PHP >> 5.2.x and PHP 5.3.x concurrently. > > Yep, but only (IMHO) if the user explicitly asks for it. Would a good > solution > be for the package manager to prompt the user > "You seem to have another version (5.2.x) installed. Shall I remove > that now?" > Currently, IPS (OpenSolaris package manager) does not have this feature. I would like to avoid depending on OpenSolaris IPS feature as a solution to this problem . Unfortunately, we have to design our solution to both Indiana (Ubuntu like distribution which uses IPS) as well as for SXCE - OpenSolaris community edition (where in all PHP5 packages are integrated by default as part of installation) . >> - roll in the Apache / PHP glue module (mod_php5.so) within SUNWphp52 >> package (no need for SUNWapch22m-php5 package) and deliver the apache / >> php module under /usr/php5/<major>.<minor>/libexec/mod_php5.so and >> create an appropriate symbolic link at >> /usr/apache2/2.2/libexec/mod_php5.so . Also, always deliver a single PHP >> INI file (SUNWapch22r-php5) which will load the mod_php5.so that is >> symbolic linked to /usr/apache/2.2/libexec/mod_php5.so > > You mean, supply an ApacheXX-phpYY package that's just the symlink, > or drop it altogether? Currently, we do supply ApacheXX-PhpYY package which includes a php<XX>.ini as well as mod_php<XX>.so . However, if customer wants to try out say PHP 5.3, then he will need to currently [un] install the existing ApacheXX-PhpYY and get the latest version. > >> - Continue delivering PHP version specific Apache / PHP glue packages >> (like SUNWapch22m-php52 and SUNWapch22r-php52). It is user's >> responsibility to avoid having ending up with multiple PHP ini files >> under /etc/apache2/2.2/conf.d directory. > > Surely no package should ever overwrite an existing config file! > If that's the user's responsibility, what happens to users who don't > realise it until too late? > >> What do you guys think ? Or is there a better way to address this ? >> Your comments / thoughts on these will be much much appreciated. > > Why is there any question of multiple php.ini files? Does it differ > between PHP versions? If so, maybe php.ini could be a symlink too. > The only reason there would be multiple php.ini files would be to load a different version of php <mod_php<xx>.so> . To keep things simple, this is what I will do - Deliver PHP 5.2 binaries and extensions within SUNWphp52u package - Deliver Apache / PHP 5.2 glue files within SUNWaph22[r/m]-php52 package . If a customer wants 5.3, he will need to uninstall SUNWapch22[r/m]-php52 and replace it with SUNWapch22[r/m]-php53. This option , IMO, has the least amount of confusion to our customers.
