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
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.
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 ?
(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.
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
Also happens with the drupal7 package, which requires php53-common while many other packages (e.g. cacti, squirrelmail) require php-common.
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.
Does it work functionally as well?
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 ?
Change how? On EL-5, php-common provides php-api = 20041225, and php53-common provides php-api = 20090626.
I was thinking about php-api >= 20041225 since Smarty is compliant with php 5.1 and php 5.3
I see, and that was the change you made and tested?
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 ?
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.
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 ?
Potentially. php and php53 both provide libphp5.so, how about that instead?
Yes it would be better, but can't be an issue that there is no versionning on this component ?
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.
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.
Ok, give this koji build a test. http://koji.fedoraproject.org/koji/buildinfo?buildID=318118
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.
Excellent, thanks, I'll get this out!
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
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).
Package installation was sucessful with php and php53 with the package available in epel-testing. Karma has been updated.
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.
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.
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)
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
So the consensus seems to be to just drop the Requires on PHP completely?
# 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)
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.
(In reply to comment #31) > Requires: /usr/share/php This will not work with php-common (5.1.6)
A conditional on arch, so it gets libphp5.so/libphp5.so()(64bit) right? Also ugly.
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.
Less ugly than the conditional. Remi?
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
I see your point, I'll go with the Comment 30 solution.
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
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).
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.