- php-5.3.21-1_x86_64.rpm (base)
- php-pecl-memcache-3.0.6-1_x86_64.rpm (dependant on above because of the internal PHP ABI version change)
- php-5.4.13-1_x86_64.rpm (base)
- php-pecl-memcache-3.0.7-1_x86_64.rpm (dependant on above because of the internal PHP ABI version change)
This is a more general question about RPMs and versioning, but I'll relate it specifically to PHP as that's the bit I'm looking at, at the moment. It however could also relate to any library/package which requires a specific API/ABI version of a software (applicable equally to apache/httpd, python, etc).
I'm currently upgrading to PHP 5.4, and looking for a way to either work with yum/rpm to allow some servers to run legacy PHP 5.3, I'd like to know the best way to achieve this. The problem with the above is (if the packages are all within the one yum repository), the PHP5.3 server (version locked to 5.3) see's there's an 'upgrade' for php-pecl-memcache (3.0.6 < 3.0.7) and attempts an update, but hit's a dependency error as the package php-pecl-memcache-3.0.7 requires a PHP ABI version released with 5.4 packages.
Basically what I'm trying to work out is:
- Is there a way of making yum say, 'if I have php 5.3 packages installed, then ignore upgrades dependent on the new version'?
- Secondly, is this accomplished using a versioning system I haven't thought of yet, or the Epoch keyword within the RPM/RPMBuild?
- I've seen another approach of creating php54-common-5.4.11..., httpd24-devel-2.4.2-, python27, etc (This seems a bit messy though, when the previous versioning scheme didn't specify major version as part of the name)
- Finally, perhaps the only way of doing this is separating packages into different repositories, which poses another interesting issue with naming the package/version/revision so that you know from the filename which major version/API version/epoch it was built for. (php-pecl-memcache-3.0.7_php54_x86_65.rpm)
The thing that gets me when thinking about this, is I'm only concerned with small batches of packages at the moment. How have RHEL/Fedora package maintainers dealt with this when upgrading a major version which affects thousands of libraries (python upgrade from 2.6 to 2.7, or perl/ruby/etc)
Thanks all, I've tried to keep the question as short as possible, but it's quite complicated.