Karanbir Singh a écrit :
Jean-Marc LIGER wrote:
how do you provide a upgrade path from the distro php to the >someother< php,
We deal with yum install/update php5[-feature] and the Provides/Obsoletes options.
but if php5-feature Obsoletes: php-feature, a yum upgrade will force the user to php5.
We assume that, as it is provided in a specific repo you have to enable first, and where you can exclude php5* if you want to proceed a yum upgrade.
and how do you handle rpms for php-<feature> packages ?
All the php-<feature> are built with the same php5 rpm.
That just sounds like a really bad idea. Imagine what would happen if all of cpan was built into perl
Definitively yes or no, depending on what you are focus on :
- In a distro packaging way, you should reduce build cpu time and bandwith consumption, so you split packages every time you can, to reduce src.rpm sizes and the numbers of packages you must rebuild when some stuff need to be updated ; - In my service way, we have to reduce first human skills consumption, and we don't care about consuming some build cpu time or local network bandwith for that. So we customized a php5 packages which actually stick to our needs. Notice that with all the pecl and pear features I've had, I would have to maintain more than 50 different spec files instead of one.
One thing I forgot, our php rpm is hardened with the suhosin patch. You can look at the spec file here : http://redhat.sorbonne.fr/CentOS-5/siris/SPECS/php5.spec
why are you building all the php-<feature> stuff into the main spec ?
Apart from the easy spec file maintenance fact, I don't benefit of a high quality assurance build process like the CentOS one. So I like the idea of having all my php-<feature> built in a single pass, especially when I update php version from php.net.
Jean-Marc