Atomicorp

BerArt wrote:I have the same problem, but sitebuilder is NOT running

I'm not using sitebuilder either, but removing php-sqlite2 will effect more than just sitebuilder apparently

scott wrote:What parts of it are installed? I cant duplicate it here because Ive never had it installed

Hi,

I'm having the same issue upgrading to php 5.2.8.3 , I did not have any dependency issue upgrading to 5.2.8.1.


Thanks

joeb wrote:Hi,

I'm having the same issue upgrading to php 5.2.8.3 , I did not have any dependency issue upgrading to 5.2.8.1.

Code: Select all

Error: Missing Dependency: php <= 4.4.0 is needed by package php-sqlite2 

Thanks

Joeb,

Can you post ur whole yum update result?

Thanks,
Jonas

I think a clue can be found at the Parallels website here:

http://forum.swsoft.com/showthread.php? ... ght=SQLite

The last time I upgraded php I followed these instructions and replaced the sqlite.so file with the one they compiled (was compatible with my system). After that things worked just fine including Sitebuilder.

If removing sqlite is the only option then how does one instruct yum to remove it without the dependencies? Is there a way to do this?

http://forum.swsoft.com/showthread.php? ... ght=SQLite

pfff a bit to complicated for me

j0ney3 wrote:
Can you post ur whole yum update result?

Thanks,
Jonas

Here it is:

Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package php.i386 0:5.2.8-3.el4.art set to be updated
--> Running transaction check
--> Processing Dependency: php-common = 5.2.8-3.el4.art for package: php
--> Processing Dependency: php-cli = 5.2.8-3.el4.art for package: php
--> Processing Dependency: php = 5.2.8-1.el4.art for package: php-devel
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package php-devel.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-cli.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-common.i386 0:5.2.8-3.el4.art set to be updated
--> Running transaction check
--> Processing Dependency: php-common = 5.2.8-1.el4.art for package: php-imap
--> Processing Dependency: php-common = 5.2.8-1.el4.art for package: php-ldap
--> Processing Dependency: php-common = 5.2.8-1.el4.art for package: php-pdo
--> Processing Dependency: php-common = 5.2.8-1.el4.art for package: php-mbstring
--> Processing Dependency: php-common = 5.2.8-1.el4.art for package: php-gd
--> Processing Dependency: php-common = 5.2.8-1.el4.art for package: php-xml
--> Processing Dependency: php-common = 5.2.8-1.el4.art for package: php-mysql
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package php-imap.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-ldap.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-xml.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-mysql.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-mbstring.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-gd.i386 0:5.2.8-3.el4.art set to be updated
---> Package php-pdo.i386 0:5.2.8-3.el4.art set to be updated
--> Running transaction check
--> Processing Dependency: libt1.so.5 for package: php-gd
--> Processing Dependency: any-php-sqlite2 for package: sb-publish
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package php-sqlite2.i386 0:1.0.2-200608291848 set to be updated
---> Package t1lib.i386 0:5.1.2-2.el4.art set to be updated
--> Running transaction check
--> Processing Dependency: php <= 4.4.0 for package: php-sqlite2
--> Finished Dependency Resolution
Error: Missing Dependency: php <= 4.4.0 is needed by package php-sqlite2

joeb wrote:Hi,

I'm having the same issue upgrading to php 5.2.8.3 , I did not have any dependency issue upgrading to 5.2.8.1.

Code: Select all

Error: Missing Dependency: php <= 4.4.0 is needed by package php-sqlite2 

Thanks

Joeb, I also did not have this issue when upgrading to 5.2.8.1. Although Scott says it is not an ART issue perhaps it is.

Ok, for everyone who IS NOT USING SITEBUILDER, here's what I did to remove it and the deps it causes on this latest update
After that the update worked perfect.

j0ney3 wrote:Ok, for everyone who IS NOT USING SITEBUILDER, here's what I did to remove it and the deps it causes on this latest update

Code: Select all

yum remove sitebuilder
yum remove sb-publish

After that the update worked perfect.

That's interesting since both those packages do not list php-sqlite2 as a dependency and hence not removed. Begs the question as to what is going on then.

I executed the following:

yum resolvedep php-sqlite2

Answer was:

0:php-pdo-5.2.8-1.el5.art.x86_64

Does this not work the other way as well? That is that php-pdo is actually the package that is dependent on php-sqlite2? What I am getting at is that this package is the one responsible for the dependency error.

Further:

yum deplist php-sqlite2

Finding dependencies:
package: php-sqlite2.x86_64 5.1.6-200705230937
dependency: php <= 5.2.0
provider: php.x86_64 5.1.6-20.el5
provider: php.x86_64 5.1.6-20.el5_2.1
dependency: libc.so.6()(64bit)
provider: glibc.x86_64 2.5-24
provider: glibc.x86_64 2.5-24.el5_2.2
dependency: php >= 5.1.0
provider: php.x86_64 5.1.6-20.el5
provider: php.x86_64 5.2.8-1.el5.art
provider: php.x86_64 5.2.8-3.el5.art
provider: php.x86_64 5.1.6-20.el5_2.1
dependency: rtld(GNU_HASH)
provider: glibc.i686 2.5-24
provider: glibc.x86_64 2.5-24
provider: glibc.i686 2.5-24.el5_2.2
provider: glibc.x86_64 2.5-24.el5_2.2
dependency: libc.so.6(GLIBC_2.3)(64bit)
provider: glibc.x86_64 2.5-24
provider: glibc.x86_64 2.5-24.el5_2.2
dependency: libc.so.6(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.5-24
provider: glibc.x86_64 2.5-24.el5_2.2

mdtiberi wrote:I executed the following:

yum resolvedep php-sqlite2

Answer was:

0:php-pdo-5.2.8-1.el5.art.x86_64

Does this not work the other way as well? That is that php-pdo is actually the package that is dependent on php-sqlite2? What I am getting at is that this package is the one responsible for the dependency error.

Further:

yum deplist php-sqlite2

Finding dependencies:
package: php-sqlite2.x86_64 5.1.6-200705230937
dependency: php <= 5.2.0
provider: php.x86_64 5.1.6-20.el5
provider: php.x86_64 5.1.6-20.el5_2.1
dependency: libc.so.6()(64bit)
provider: glibc.x86_64 2.5-24
provider: glibc.x86_64 2.5-24.el5_2.2
dependency: php >= 5.1.0
provider: php.x86_64 5.1.6-20.el5
provider: php.x86_64 5.2.8-1.el5.art
provider: php.x86_64 5.2.8-3.el5.art
provider: php.x86_64 5.1.6-20.el5_2.1
dependency: rtld(GNU_HASH)
provider: glibc.i686 2.5-24
provider: glibc.x86_64 2.5-24
provider: glibc.i686 2.5-24.el5_2.2
provider: glibc.x86_64 2.5-24.el5_2.2
dependency: libc.so.6(GLIBC_2.3)(64bit)
provider: glibc.x86_64 2.5-24
provider: glibc.x86_64 2.5-24.el5_2.2
dependency: libc.so.6(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.5-24
provider: glibc.x86_64 2.5-24.el5_2.2

Yeah , but if you run :

yum deplist sb-publish

package: sb-publish.noarch 3.0.1-200610111446
dependency: php-ioncube-loader >= 3.0
provider: php-ioncube-loader.i386 1:3.0-2.el4.art
provider: php-ioncube-loader.i386 1:3.1-7.el4.art
provider: php-ioncube-loader.i386 1:3.1-4.el4.art
provider: php-ioncube-loader.i386 1:3.1-2.el4.art
provider: php-ioncube-loader.i386 1:3.0-1.el4.art
provider: php-ioncube-loader.i386 3.0-06101212
provider: php5-ioncube-loader.i386 3.1-07070414
dependency: any-php-sqlite2
provider: php-pdo.i386 5.2.8-1.el4.art
provider: php-sqlite2.i386 1.0.2-200608291848
provider: php5-sqlite2.i386 5.1.6-200707041520
dependency: psa-php-configurator >= 1.1.0
provider: psa-php4-configurator.noarch 1.4.0-cos4.build86080722.02

as you see php-pdo and php5-sqlite2 are required.

Thanks joeb. That helps isolate the issue.

I had this problem on one box, I removed sb-publish

rpm -e sb-publish

then upgraded php, and then reinstalled sb-publish

hostingguy wrote:I had this problem on one box, I removed sb-publish

rpm -e sb-publish

then upgraded php, and then reinstalled sb-publish

yeah, that actually looks like the easiest way to get around this.