Bug 700179 - Unable to install php-Smarty with the php53 components
Unable to install php-Smarty with the php53 components
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: php-Smarty (Show other bugs)
el5
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-27 12:47 EDT by Olivier BONHOMME
Modified: 2012-06-22 12:01 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-22 12:01:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Spec for compat-php package, which provides php for php53 package (549 bytes, text/plain)
2011-06-27 07:01 EDT, Tomasz Ostrowski
no flags Details

  None (edit)
Description Olivier BONHOMME 2011-04-27 12:47:54 EDT
Description of problem:

Since Centos 5.6, php53 suite has been integrated in the RPM tree. If we consider install php-Smarty with php53 installed, yum raises a dependency error. Yum wants to install php package and then php-common => A conflict is raised because php53-common is installed.

Version-Release number of selected component (if applicable): 2.6.26-1.el5


How reproducible:

Try to install php-Smarty with php53 installed

Steps to Reproduce:
1.Install php53 package ==> yum install php53
2.Install php-Smarty ==> yum install php-Smarty
3.
  
Actual results:

Conflict raised by yum ! 

# yum install php-Smarty
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * epel: mirrors.ircam.fr
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php-Smarty.noarch 0:2.6.26-1.el5 set to be updated
--> Processing Dependency: php >= 5.1.6-3.5 for package: php-Smarty
--> Running transaction check
---> Package php.i386 0:5.1.6-27.el5_5.3 set to be updated
--> Processing Dependency: php-common = 5.1.6-27.el5_5.3 for package: php
--> Processing Dependency: php-cli = 5.1.6-27.el5_5.3 for package: php
--> Processing Dependency: libaspell.so.15 for package: php
--> Processing Dependency: libpspell.so.15 for package: php
--> Running transaction check
---> Package aspell.i386 12:0.60.3-7.1 set to be updated
--> Processing Dependency: aspell-en for package: aspell
---> Package php-cli.i386 0:5.1.6-27.el5_5.3 set to be updated
---> Package php-common.i386 0:5.1.6-27.el5_5.3 set to be updated
--> Running transaction check
---> Package aspell-en.i386 50:6.0-2.1 set to be updated
--> Processing Conflict: php53-common conflicts php-common
--> Finished Dependency Resolution
php53-common-5.3.3-1.el5_6.1.i386 from installed has depsolving problems
  --> php53-common conflicts with php-common
Error: php53-common conflicts with php-common
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest


Expected results:

php-Smarty is installed

Additional info:

I tested a solution which seems to work : Replace the php requirement by /usr/bin/php in the spec file but i don't know if it authorized by the EPEL policy
Comment 1 Christof Damian 2011-05-04 03:56:57 EDT
I have mentioned this on the fedora-php-devel list, because it is a general problem with all php packages. Lets see what we come up with.
Comment 2 Olivier BONHOMME 2011-05-04 05:54:51 EDT
I saw the discussion on the ML. Do you think it could be a good idea to submit a php53-smarty package or should it be wait an EPEL team decision about that point ?
Comment 3 Christof Damian 2011-05-04 06:47:06 EDT
(In reply to comment #2)
> I saw the discussion on the ML. Do you think it could be a good idea to submit
> a php53-smarty package or should it be wait an EPEL team decision about that
> point ?

I don't think it make sense to duplicate all packages (well, I don't want to maintain those anyway). It should be possible to just require "a PHP" instead of a specific one. Maybe php53 should provide php-common.
Comment 4 Olivier BONHOMME 2011-05-04 07:01:04 EDT
I looked on the php53 specfile provided by CentOS since 5.6 and unfortunately php53 doesn't provides php-common but raises a conflicts with it.

So in that case i don't know what is the correct policy : 
 - Open a bug in CentOS ?
 - Adapt the EPEL specfile in order to be compliant with these new packages without breaking compatibility with others php versions (php 5.1 and php53 IUS)

Regards
Comment 5 Raman Gupta 2011-06-23 12:51:01 EDT
Also happens with the drupal7 package, which requires php53-common while many other packages (e.g. cacti, squirrelmail) require php-common.
Comment 6 Tomasz Ostrowski 2011-06-27 07:01:36 EDT
Created attachment 510070 [details]
Spec for compat-php package, which provides php for php53 package

I've worked around this issue creating a special, empty compat-php package which provides "php" and requires "php53". This way I can install a package that requires "php" with php53.
Comment 7 Gwyn Ciesla 2011-06-28 09:14:10 EDT
Does it work functionally as well?
Comment 8 Olivier BONHOMME 2012-05-06 10:38:25 EDT
Hello,

I started working again on my opensource project which uses Smarty and I still have issues about this php* and php53* packages.

After looking a little bit more, I saw that all the php packages provides a php-api target with a specific version number.

So I was thinking, why not making the dependency against the php-api version in stead of the binary php.

I updated the smarty SPEC file changing the dependency and I could install and use Smarty with both versions. (php and php53).

Won't it be possible to make such a change for Smarty and maybe for all EPEL packages concerned ?
Comment 9 Gwyn Ciesla 2012-05-07 10:46:53 EDT
Change how?  On EL-5, php-common provides php-api = 20041225, and php53-common provides php-api = 20090626.
Comment 10 Olivier BONHOMME 2012-05-07 11:17:18 EDT
I was thinking about php-api >= 20041225 since Smarty is compliant with php 5.1 and php 5.3
Comment 11 Gwyn Ciesla 2012-05-07 11:24:51 EDT
I see, and that was the change you made and tested?
Comment 12 Olivier BONHOMME 2012-05-07 13:11:11 EDT
Yes it's the test what I did. Unfortunately, I forgot something important : On a fresh install my php-Smarty install won't be complete because the php package won't be installed.

So my idea was bad sorry about that.

Then, I started looking to the php and php53 packages and I saw the following : 

$ rpm -qp --provides php-5.1.6-32.el5.i386.rpm 
config(php) = 5.1.6-32.el5
libphp5.so  
mod_php = 5.1.6-32.el5
php = 5.1.6-32.el5

and 

$ rpm -qp --provides php53-5.3.3-5.el5.i386.rpm 
config(php53) = 5.3.3-5.el5
libphp5.so  
mod_php = 5.3.3-5.el5
php53 = 5.3.3-5.el5

These two provides request show that the both packages provides mod_php and with a strict version requirement.

So the dependency could be on mod_php or even in libphp5.so even if I think that it is less relevant.

In that case we could imagine the following use cases : 

- There is no PHP version installed on the system and the sysadmin doesn't care about the php version installed => yum install php-Smarty will install php.

- There is no PHP version installed on the system and the sysadmin WANTS php53 => So he can install php53 by hand using yum install php53 and after that php-Smarty will be installable without conflicts because the dependency will be on mod_php which is provided by php and php53.

Moreover if the sysadmin clearly wants php53 and avoid conflicts, it can also excludes all the php (5.1) packages from its yum configuration in order to be sure to only have php53 packages installed. In that case a yum install php-Smarty will install php53 because all the php packages will be disabled.

Of course I totally agree it's not a really proper solution but maybe it could resolves some cases with an additional documentation on EPEL wiki.

What do you think about that ?
Comment 13 Gwyn Ciesla 2012-05-07 15:04:36 EDT
Well, I looked at:

https://fedoraproject.org/wiki/Packaging:PHP

And I think the Other Packages section is what applies here.  Given that, I think php-api >= 20041225 makes the most sense.  I'll do that unless you object.
Comment 14 Olivier BONHOMME 2012-05-08 08:49:54 EDT
It could be a solution but in that case, php-Smarty will only depends on php-common or php53-common and if php or php53 is not installed, it won't be.

Maybe it can be a problem for the user who wants to install Smarty can't it ?
Comment 15 Gwyn Ciesla 2012-05-09 09:27:03 EDT
Potentially.  php and php53 both provide libphp5.so, how about that instead?
Comment 16 Olivier BONHOMME 2012-05-09 09:48:12 EDT
Yes it would be better, but can't be an issue that there is no versionning on this component ?
Comment 17 Gwyn Ciesla 2012-05-09 09:54:35 EDT
I wouldn't imagine so.  It's my understanding that Smarty needs PHP5, and really doesn't care what version it gets, so long as it's equal to or greater than what's available in EL-5.
Comment 18 Olivier BONHOMME 2012-05-09 10:47:45 EDT
Ok. So I don't have comment to do against that. If you think that's okay with the EPEL policy, it's okay for me.
Comment 19 Gwyn Ciesla 2012-05-09 11:16:28 EDT
Ok, give this koji build a test.

http://koji.fedoraproject.org/koji/buildinfo?buildID=318118
Comment 20 Olivier BONHOMME 2012-05-13 09:14:44 EDT
Hello,

I downloaded your package on koji site and I tested it with mock considering the two following use cases : 

$ mock install php-Smarty-2.6.26-1.el5.1.noarch.rpm

and 

$ mock install php53 php53-common php-Smarty-2.6.26-1.el5.1.noarch.rpm 

and of course with a mock init between the two commands.

For every case, the package has been installed successfully.
Comment 21 Gwyn Ciesla 2012-05-14 10:27:12 EDT
Excellent, thanks, I'll get this out!
Comment 22 Fedora Update System 2012-05-14 10:28:26 EDT
php-Smarty-2.6.26-1.el5.1 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/php-Smarty-2.6.26-1.el5.1
Comment 23 Fedora Update System 2012-05-14 22:11:59 EDT
Package php-Smarty-2.6.26-1.el5.1:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing php-Smarty-2.6.26-1.el5.1'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5880/php-Smarty-2.6.26-1.el5.1
then log in and leave karma (feedback).
Comment 24 Olivier BONHOMME 2012-05-27 08:22:18 EDT
Package installation was sucessful with php and php53 with the package available in epel-testing.

Karma has been updated.
Comment 25 Fedora Update System 2012-05-30 21:08:13 EDT
php-Smarty-2.6.26-1.el5.1 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 David Burrows 2012-06-03 22:42:29 EDT
Unfortunately this bug is not fixed.  On 64bit systems the dependency for libphp5.so is listed as such:
libphp5.so()(64bit)

This apparently does not match with libphp5.so, and therefore generates the following error when installing/upgrading:
Error: Missing Dependency: libphp5.so is needed by package php-Smarty-2.6.26-1.el5.1.noarch (epel)

The proposed solution of having an noarch package depend on an arch specific one such as "libphp5.so" appears to be broken anyway, and would fail to work with CGI or php-cli.

I use php53u from IUS, which does the sensible thing of providing "php", the EL package "php53" does not.

Perhaps the best way to fix this is the above mentioned "compat-php" package, which provides the php dependency for php53.  Maybe it should be called "php53-compat" though.  This will not work with php-cgi/php-cli though, which also does not provide php dependency.  Afaik, rpm spec does not allow the use of OR with dependencies.  Eg depends on php or php-cgi.

Given all of the above, I vote for just removing the php requirement altogether.  Problem solved.
Comment 27 Brian Pitts 2012-06-04 18:02:53 EDT
Seconding that this need to be reopened and the decision revisited.

$ repoquery --provides php
config(php) = 5.1.6-34.el5_8
libphp5.so()(64bit)
mod_php = 5.1.6-34.el5_8
php = 5.1.6-34.el5_8

$ repoquery --requires php-Smarty
libphp5.so

$ sudo yum update php-Smarty
[snip]
Resolving Dependencies
--> Running transaction check
---> Package php-Smarty.noarch 0:2.6.26-1.el5.1 set to be updated
--> Processing Dependency: libphp5.so for package: php-Smarty
--> Finished Dependency Resolution
php-Smarty-2.6.26-1.el5.1.noarch from epel has depsolving problems
  --> Missing Dependency: libphp5.so is needed by package php-Smarty-2.6.26-1.el5.1.noarch (epel)
Error: Missing Dependency: libphp5.so is needed by package php-Smarty-2.6.26-1.el5.1.noarch (epel)
Comment 28 Remi Collet 2012-06-07 02:53:40 EDT
Sorry if I come really late on this bug...

Requiring libphp5.so seems a very bad idea/solution.

libphp5.so is not a library but a private shared so (an apache plugin), and this should not be provided (should be filtered in php RPM)

If you really need to require the php module for apache, use "mod_php"

But do you really requires apache ?
This is not a web app. php-Smarty could probably be used by a web app with another webserver ?

I think, it's the "webapp", when providing an apache configuration file to require php and apache. Not to a library
Comment 29 Gwyn Ciesla 2012-06-11 10:28:07 EDT
So the consensus seems to be to just drop the Requires on PHP completely?
Comment 30 Remi Collet 2012-06-11 10:47:31 EDT
# phpci print --recursive --report extension /usr/share/php/Smarty
-------------------------------------------------------------------------------
  EXTENSION                                        PECL   VERSION         COUNT
-------------------------------------------------------------------------------
  Core                                                    4.0.0             734
  date                                                    4.0.0              35
  ereg                                                    4.0.0  5.3.0        2
  pcre                                                    4.0.0             121
  standard                                                4.0.0             677
  tokenizer                                          0.1  4.2.0               2
-------------------------------------------------------------------------------

(In reply to comment #29)
> So the consensus seems to be to just drop the Requires on PHP completely?

As all required extensions are provided by base package : YES

But it will raise a (very) small issue because Smarty install in /usr/share/php which is own by php53-common (but not by php-common)

You can also 
Requires: php-date php-pcre php-tokenizer 
Which are provided by both php-common and php53-common (don't know why php-ereg isn't provided... small bug... well deprecated extension)

Definitively php53-common should provide php-common which is the usual depency used (and we are trying to fix in EPEL, something which should be fixed elsewhere... in RHEL)
Comment 31 Gwyn Ciesla 2012-06-11 11:02:46 EDT
Sadly, directory ownership isn't a small issue.  How about a simple:

Requires: /usr/share/php

?

Ugly, but it will still work after php53 is fixed.
Comment 32 Remi Collet 2012-06-11 11:29:27 EDT
(In reply to comment #31)
> Requires: /usr/share/php

This will not work with php-common (5.1.6)
Comment 33 Gwyn Ciesla 2012-06-11 11:45:44 EDT
A conditional on arch, so it gets libphp5.so/libphp5.so()(64bit) right?  Also ugly.
Comment 34 Olivier BONHOMME 2012-06-11 11:56:27 EDT
Hello,

First, sorry for the bad RPM generated. I didn't think about the 64 Bit architecture since for my activity I use only 32 bits architecture.

What about considering mod_php which is provided by both RPM (32 and 64 bits) as I proposed be

$ rpm -qp --provides php53-5.3.3-7.el5_8.x86_64.rpm
config(php53) = 5.3.3-7.el5_8
libphp5.so()(64bit)  
mod_php = 5.3.3-7.el5_8
php53 = 5.3.3-7.el5_8

$ rpm -qp --provides php53-5.3.3-7.el5_8.i386.rpm 
attention: php53-5.3.3-7.el5_8.i386.rpm: Entête V3 DSA signature: NOKEY, key ID e8562897
config(php53) = 5.3.3-7.el5_8
libphp5.so  
mod_php = 5.3.3-7.el5_8
php53 = 5.3.3-7.el5_8

Maybe it's an uglyess solution.
Comment 35 Gwyn Ciesla 2012-06-11 12:00:55 EDT
Less ugly than the conditional.  Remi?
Comment 36 Remi Collet 2012-06-11 12:25:44 EDT
As I said in Comment 28: php-Smarty doesn't have to require php/httpd

See my proposal for PHP Guildelines:
http://lists.fedoraproject.org/pipermail/packaging/2012-June/008504.html

Also see my proposal in Comment 30:
Requires: php-date php-pcre php-tokenizer
Comment 37 Gwyn Ciesla 2012-06-11 12:33:06 EDT
I see your point, I'll go with the Comment 30 solution.
Comment 38 Fedora Update System 2012-06-11 12:46:46 EDT
php-Smarty-2.6.26-1.el5.2 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/php-Smarty-2.6.26-1.el5.2
Comment 39 Fedora Update System 2012-06-14 22:11:01 EDT
Package php-Smarty-2.6.26-1.el5.2:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing php-Smarty-2.6.26-1.el5.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6129/php-Smarty-2.6.26-1.el5.2
then log in and leave karma (feedback).
Comment 40 Fedora Update System 2012-06-22 12:01:47 EDT
php-Smarty-2.6.26-1.el5.2 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.