Sriram Natarajan wrote:
>
[Redirecting to webstack-discuss to avoid multiple lists on an
extended thread]
> With nevada build 79, we integrated the following PHP packages -
> SUNWphp524root, SUNWphp524core , SUNWphp524usr, SUNWphp524doc,
> SUNWphp524man etc. Going forward, I would like to get every one's views
> on consolidating our packages to reflect something like
Yes, this need attention. The way it is set up currently, every bug
fix is an entirely new set of packages ;-(
> - 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?
> - 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).
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.)
> - 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.
The tricky bit in the package renaming, I suspect, will be the upgrade
scenario.
--
Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
