In https://fedoraproject.org/wiki/Packaging:EPEL#PHP_ABI_Check_Handling
%if 0%{?php_zend_api}
Must be replace by
%if 0%{?php_zend_api:1}
Because, with latest PHP version this value is not an integer (but an arch specific string)
I'm sorry, but I think this is broken. From my point of view, the value in /etc/rpm/macros.php is not architecture specific. Because things get architecture specific during build, but not as long as it's source only. Instead developers should use %{php_zend_api}%{?_isa} in their *.spec files - the same, as you do at package requirements as well. Why should there be any exception for Provides of API/ABI?
Especially...what happens if php-devel.x86_64 and php-devel.i686 is installed with /etc/rpm/macros.php?
I'd say the fix as proposed is a no-brainer, "just do it".
Going beyond that and arguing about the arch'ness of %{php_zend_api} goes beyond the scope of this otherwise simple EasyFix to the php guidelines. (A good conversation to be had, surely, but here... no)
I'm wondering why this EPEL guideline page isn't somewhere where the EPEL folks can edit it without going through the packaging committee.
What happens to /etc/rpm/macros.php, if I install php-devel.i686 and php-devel.x86_64? The i686 one ships "%php_zend_api 220091234(i686)" while the x86_64 one ships "%php_zend_api 220091234(x86_64)".
Anyway, I don't treat this as something to fix in the EPEL guidelines but to be fixed in the PHP package in Rawhide itself. That's why I opened https://bugzilla.redhat.com/show_bug.cgi?id=680811 initially and proposed there a fix.
Replying to [comment:5 tibbs]:
Indeed, let's move the information here for now: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines
+1 to moving this to an EPEL controlled space.
I also asked nirik (as a member of the EPEL SIG) and he thought moving it was a good idea.
Page moved to EPEL:Packaging.
Login to comment on this ticket.