[opensuse-packaging] php-devel vs. php5-devel vs. php53-devel
While updating XCache to a new major version to gain PHP 5.4 support, etc.[1] I encountered problems building it for some SLES versions. I added an SLE_11_SP3 repo to my branch project to test building for SP3 (SLE 11 SP2 PHP extensions packages are no good for SP3, see [2]), and the build failed with "nothing provides php5-devel". Indeed, the php53-devel package in SP3 (also SP2) provides php-devel and php53-devel but not php5-devel. Unlike SP2, there is no more php5-devel package (which was 5.2.x in <= SP2). I had previously made a 'php53-dummy-deps' RPM that depends on php53-devel and provides php5-devel in order to more easily do local builds of packages like this against php53-devel from SP2, but that's probably not a workable solution for the OBS. In any case I decided to upload it to my home project now in case it might be useful to others [3]. Back to xcache... I tried changing its BuildRequires from php5-devel to 'php-devel', since that's provided by every distro. That worked everywhere except for SLE_11_SP2, where it failed with "unresolvable: have choice for php-devel", because that's provided by *both* php5-devel and php53-devel. Ugh. I solved this by adding a Prefer: php5-devel line to my meta prjconf à la [4] but I don't know how that would translate to the OBS server:php:extensions repo. Also, all the extensions there have BuildRequires: php5-devel to every single one would have to be changed to php-devel... what a mess! This would've been much easier if Novell/SUSE made php53-devel provide 'php5-devel' but I guess they had their reasons, maybe to avoid the ambiguous provides issue in SP2. Perhaps there's a better solution with osc meta (or similar) to work around this? prjconf Substitute looks promising but the %sles_version macro not changing with different SPs makes that problematic. Thanks, Andrew Daugherity [1] https://build.opensuse.org/package/show/home:adaugherity:branches:server:php... It's mostly ready but I'm waiting to submit it until these build issues are sorted. [2] https://bugzilla.novell.com/show_bug.cgi?id=830214 [3] https://build.opensuse.org/package/show/home:adaugherity/php53-dummy-deps It also provides php5-hash, etc. to work around similar problems (php53 provides php-hash, but not php5-hash, etc.). [4] http://lists.opensuse.org/opensuse-packaging/2011-01/msg00156.html -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 23.07.2013 21:26, Andrew Daugherity wrote:
While updating XCache to a new major version to gain PHP 5.4 support, etc.[1] I encountered problems building it for some SLES versions. I added an SLE_11_SP3 repo to my branch project to test building for SP3 (SLE 11 SP2 PHP extensions packages are no good for SP3, see [2]), and the build failed with "nothing provides php5-devel".
Indeed, the php53-devel package in SP3 (also SP2) provides php-devel and php53-devel but not php5-devel. Unlike SP2, there is no more php5-devel package (which was 5.2.x in <= SP2).
Which was the wrong one anyway.
I had previously made a 'php53-dummy-deps' RPM that depends on php53-devel and provides php5-devel in order to more easily do local builds of packages like this against php53-devel from SP2, but that's probably not a workable solution for the OBS. In any case I decided to upload it to my home project now in case it might be useful to others [3]. Indeed it is useful.
Back to xcache... I tried changing its BuildRequires from php5-devel to 'php-devel', since that's provided by every distro. That worked everywhere except for SLE_11_SP2, where it failed with "unresolvable: have choice for php-devel", because that's provided by *both* php5-devel and php53-devel. Ugh. I solved this by adding a Prefer: php5-devel line to my meta prjconf à la [4] but I don't know how that would translate to the OBS server:php:extensions repo. Also, all the extensions there have BuildRequires: php5-devel to every single one would have to be changed to php-devel... what a mess!
You can resolve the choice in prjconf. Add a line: Prefer: php53-devel I agree that the SP2 php53 thing was not a painless move. Anyway, php 5.2 is history and php53 is in "security fix mode". But that's a different can of little animals.
This would've been much easier if Novell/SUSE made php53-devel provide 'php5-devel' but I guess they had their reasons, maybe to avoid the ambiguous provides issue in SP2.
Perhaps there's a better solution with osc meta (or similar) to work around this? prjconf Substitute looks promising but the %sles_version macro not changing with different SPs makes that problematic. you can always default to php53 as long as SUSE doesn't ship any SLES version where php53 does exist AND is the worse option.
-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Jul 23, 2013, at 2:39 PM, Ralf Lang
On 23.07.2013 21:26, Andrew Daugherity wrote:
Indeed, the php53-devel package in SP3 (also SP2) provides php-devel and php53-devel but not php5-devel. Unlike SP2, there is no more php5-devel package (which was 5.2.x in <= SP2).
Which was the wrong one anyway. I agree (would've been better to have had php52 and php53, with php52 Obsoletes: php5 < 5.3), but that's the way it was shipped, and since packages in the OBS repo server:php:extensions/SLE_11_SP2 have always been built against the 5.2 php5-devel packages, I don't think it would be advisable to suddenly change this.
Fortunately, once an SLE_11_SP3 repo is turned on for server:php:extensions, those packages should work fine with SP2's php53-* also. I used the extension packages from the s:p:ext/server_php_SLE_11 repo with SP2's php53 just fine while server:php was 5.3.x. Now that it's 5.4 that of course no longer works. :-)
Back to xcache... I tried changing its BuildRequires from php5-devel to 'php-devel', since that's provided by every distro. That worked everywhere except for SLE_11_SP2, where it failed with "unresolvable: have choice for php-devel", because that's provided by *both* php5-devel and php53-devel. Ugh. I solved this by adding a Prefer: php5-devel line to my meta prjconf à la [4] but I don't know how that would translate to the OBS server:php:extensions repo. Also, all the extensions there have BuildRequires: php5-devel to every single one would have to be changed to php-devel... what a mess!
You can resolve the choice in prjconf. Add a line: Prefer: php53-devel Again, while this will fix the SP2 ambiguity in the other direction, it would be a radical change for the SLE_11_SP2 repo. There's also still the problem of updating every single package in the OBS extensions repo with s/php5-devel/php-devel/.
I agree that the SP2 php53 thing was not a painless move. Anyway, php 5.2 is history and php53 is in "security fix mode". But that's a different can of little animals.
This would've been much easier if Novell/SUSE made php53-devel provide 'php5-devel' but I guess they had their reasons, maybe to avoid the ambiguous provides issue in SP2.
Perhaps there's a better solution with osc meta (or similar) to work around this? prjconf Substitute looks promising but the %sles_version macro not changing with different SPs makes that problematic. you can always default to php53 as long as SUSE doesn't ship any SLES version where php53 does exist AND is the worse option. Which, again, is SP2, for certain values of "worse".
Thanks for the pointers though; I now have what I believe is a working meta prjconf that keeps SP2 as-is and fixes SP3, and does not require modifying every package with s/php5-devel/php-devel/: ==== %if 0%{?sles_version} == 11 # php53-devel provides only 'php-devel', not 'php5-devel' Substitute: php5-devel php-devel= # on SP2 the 'php-devel' symbol is provided by both php5-devel and php53-devel Prefer: php5-devel %endif ==== Now, how do I go about a) requesting this meta prjconf be added to the OBS server:php:extensions project, and b) getting the SLE_11_SP3 repo turned on for that project (already filed bnc#830214, not to be impatient, but is that the right channel for this)? Thanks, Andrew Daugherity Systems Analyst Division of Research, Texas A&M University -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 23/07/13 15:26, Andrew Daugherity escribió:
This would've been much easier if Novell/SUSE made php53-devel provide 'php5-devel' but I guess they had their reasons, maybe to avoid the ambiguous provides issue in SP2.
There is a probably a reason why it remained that way. (hint: touch old PHP versions in old distros and kittens will suffer never ending ,eternal punishment ! :-) ) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 23.07.2013 21:47, Cristian Rodríguez wrote:
El 23/07/13 15:26, Andrew Daugherity escribió:
This would've been much easier if Novell/SUSE made php53-devel provide 'php5-devel' but I guess they had their reasons, maybe to avoid the ambiguous provides issue in SP2.
There is a probably a reason why it remained that way. (hint: touch old PHP versions in old distros and kittens will suffer never ending ,eternal punishment ! :-) )
Yes, breaking pre-5.3 code is easy with this upgrade. A bunch of deprecated functions (throwing warnings into logs) and removed functions/aliases/extensions (breaking stuff for real). I think mhash was the most prominent one. On the other hand, having a php which is both SLES supported AND capable of running the latest phpunit & friends would be thrilling. The best thing we can do for now is Prefer: php53 in prjconf and hope stuff builds. Can we settle for the php-devel symbol (not package name) in the next openSUSE releases? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (3)
-
Andrew Daugherity -
Cristian Rodríguez -
Ralf Lang