Jyri Virkki wrote:
>
>
>> - Include only major and minor version in the package names and choose
>> the package name to be more consistent with the rest of SFW
>> consolidation.. For example, new php package could include only -
>> SUNWphp52usr, SUNWphp52root and SUNWphp52doc. Consolidate SUNWphp524usr
>> and SUNWphp524core into SUNWphp524usr.
>>
>
> Yes. Also, might as well use the more prevalent r|u|d ending instead
> of root|usr|doc
>
> The important investigation to do is whether the most appropriate
> versioning is 'major' or 'major.minor'. I see you're suggesting the
> latter (i.e. SUNWphp52r instead of SUNWphp5r), but it'll be good to
> investigate it thoroughly (which you may have done already?)
>
> Does the PHP community seek to maintain interface compatibility
> across minor releases as a rule (5.1 -> 5.2 -> 5.3) or not?
>
>
>
Going by past history, there is some amount of 'incompatibility'
introduced with every 'minor' release . For example, PHP has a separate
page to track migration from 5.1 to 5.2. One can get more information on
backward incompatibilities introduced with every minor release from -
http://us3.php.net/manual/en/migration52.incompatible.php
Hence, it would be appropriate to include 'major'.'minor' in our package
names as well as within our installation location. However, as I stated
earlier, it doesn't give us much benefit by also including the 'sub
minor' revision within our packages as we currently do.
thanks
sriram
>> - Deliver all third party PHP extensions like memcache, suhosin in its
>> own package. This way, we can reduce the number of dependencies required
>> to install PHP packages on Indiana . Please note that we already deliver
>> MySQL and PostgreSQL extension in a separate package.
>>
>
> There are a ton of extensions, so I'd prefer to avoid such an
> explosion of packages. My recommendation is to split into separate
> packages whenever there is a clear advantage, but not otherwise
> (suhosin for example doesn't strike me as a prime candidate).
>
>
Well, the reason I was suggesting for a separate package is that
currently we do not enable by default all the third party extensions
that we bundle (for example - suhosin , tcpwrap or idn). Currently,
with SXDE 01/08 , you might notice that we enable some extensions (all
of them that is shipped with PHP distribution) and disable third party
extensions like Suhosin, IDN, Tcpwrap, DTrace, XDebug etc. Instead, if
we did bundle these third party extensions as a separate package then
our behavior could be more consistent.
> Two reasons that come to mind for splitting into a separate package:
>
> 1. Extensions that have major dependencies that not everyone
> will have installed or want to install. MySQL & Postgres extensions
> are prime examples. No reason I should be forced to install all of
> both databases just to use PHP. On the flip side, suhosin.so depends
> only on libc and libm.. which isn't much of a burden..
> 2. If the mere presence of the extension or its configuration causes
> significant problems for those _not_ using it. ("Problem" might be
> performance or config conflicts or other.. I don't have a particular
> example in mind but I can see how there might be something in this bucket)
>
> (Deciding exactly which extensions to split is probably more of an
> ongoing work area, so I probably wouldn't bundle it with the version
> update putback plans.)
>
>
PHP 'memcache' extension that is now available with Nevada build 84
requires 'memcache' and 'libevent' packages to be available. So, I was
thinking , going forward, to move 'memcache' extension to a separate
package.
>> - Install php 5.2 series under /usr/php5/5.2 and under /etc/php5/5.2
>> location. Appropriately, create a symbolic link for /usr/php5/5.2/bin to
>> /usr/php5/bin so that sub directories like bin, lib etc can point to the
>> latest version of PHP5
>>
>
> PHP currently already delivers this, so presumably it would continue
> doing so.. so yes.
>
Yes
> The tricky bit in the package renaming, I suspect, will be the upgrade
> scenario.
>
>
Why do you this to be an issue . Considering that these will be new
packages and new installation location, I would expect that upgrade
shouldn't be a problem
- Sriram
