New install CentOS 5.7 php53 conflicts with phpcommon

17 posts / 0 new
Last post
#1 Thu, 02/16/2012 - 16:11
jflesher

New install CentOS 5.7 php53 conflicts with phpcommon

This is a new host at http://myhosting.com/ CentOS 5.7 PHP 5.1

Error: php53-common conflicts with php-common

I tried uninstalling PHP, it didn't help, it has 5.1 installed, uninstalling put 5.1 back in, I installing the bleading edge repos, now php is a 5.2, It looks like its still trying to upgrade to 5.3.

It seems to be in the install script, what can I do?

Update: Does it need to upgrade to php 5.3?

Thu, 02/16/2012 - 18:24
andreychek

Howdy,

Well, it looks like you have some conflicting packages there... the CentOS PHP 5.1.6 packages (php-) conflict with the CentOS PHP 5.3.3 packages (php53-).

You could install those php53-* packages in place of the original php-* packages, but you can't have them both at the same time.

So if you'd like PHP 5.3.3, what you'd do to get that is remove all the php-* packages, and then install the php53-* packages in their place.

-Eric

Thu, 02/16/2012 - 18:41 (Reply to #2)
jflesher

The Real question is why is the VM installer upgrading it to PHP 5.3, this is a new install, currently its at 5.2, which is fine for me, so why is it forceing an upgrade.

I did uninstall php*, then installed php53, but why this is needed is because the VM install script is forcing the upgrade, it should be an option, maybe a question or command line argument.

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Thu, 02/16/2012 - 19:02 (Reply to #3)
jflesher

I tried:
yum remove php* -y
yum remove php-common
Setting up Remove Process
No Match for argument: php-common
Loading mirror speeds from cached hostfile
* base: mirror.fdcservers.net
* extras: mirror.lug.udel.edu
* updates: mirror.rackspace.com
virtualmin-bleed
Package(s) php-common available, but not installed.
>>>>
yum install php53

Running Transaction
Installing : php53-common 1/3
Installing : php53-cli 2/3
Installing : php53 3/3
Installed:
php53.x86_64 0:5.3.3-1.el5_7.6
Dependency Installed:
php53-cli.x86_64 0:5.3.3-1.el5_7.6
php53-common.x86_64 0:5.3.3-1.el5_7.6
>>>>

Then I try reinstalling VM and get Error:

--> Processing Conflict: php53-common conflicts php-common
--> Finished Dependency Resolution
php53-common-5.3.3-1.el5_7.6.x86_64 from installed has depsolving problems
--> php53-common conflicts with php-common

FATAL - Fatal Error Occurred: Something went wrong during installation: 0

>>>>

php-common is not install, yet I still have a conflict?

and I still have no idea why VM installer is forcing an Upgrade to php53

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Thu, 02/16/2012 - 22:22
andreychek

Well, if an Install Script is asking for PHP 5.3, that suggests that the web app requires PHP 5.3 to work properly.

What output do you get if you run this command:

rpm -qa | grep php-

Thu, 02/16/2012 - 23:20 (Reply to #5)
jflesher

> rpm -qa | grep php-

wbm-php-pear-1.5-1

By Web App, you mean Virtualmin?

If so, that would explain it, by the way php-common is not installed, so tried this:
yum install php53 php53-gd php53-imap php53-mysql php53-odbc php53-pgsql php53-snmp php53-xmlrpc php53-mbstring

yum install --skip-broken php php-gd php-mysql php-odbc php-pgsql php-snmp php-xmlrpc php-mbstring

I get the same error from the command line, so its something up with the server, but more to the point, why is the script trying to install both php and php53?

If it requires php53, then this:

1. yum erase php*
2. yum install php53 php53-gd php53-imap php53-mysql php53-odbc php53-pgsql php53-snmp php-imap php53-xmlrpc php53-mbstring

and do not do a

yum install php php-common php-gd php-mysql php-odbc php-pgsql php-snmp php-xmlrpc php-mbstring

Now I do not know about a php53 version of these: php-domxml php-pear
I do see php53-xml, not sure if its like php-domxml

Otherwise you need to make the script be able to install 5.2 and 5.3 at the same time, since this seems to be my issue, I have read many post today about how to do this, most ask why, but if you do not need both, why do it, because I did not figure out how to get both installed at the same time without running into this issue.

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Fri, 02/17/2012 - 09:26
andreychek

By Web App, you mean Virtualmin?

Well, by "web app", I meant the web application you're attempting to install via an Install Script.

An install script should not attempt to install both php and php53, as those are conflicting packages.

So I suspect something else is going on here :-)

What install script are you trying to install?

Otherwise you need to make the script be able to install 5.2 and 5.3 at the same time,

This is unfortunately not possible... the available PHP 5.2 and 5.3 packages conflict with each other, only one can be installed at a time.

-Eric

Fri, 02/17/2012 - 10:58 (Reply to #7)
jflesher

I'm installing Virtualmin from ssh, via the link provided in my Liciense tab
wget -O install.sh http://software.virtualmin.com/cgi-bin/install.cgi?serial=...
So this is the install script I'm talking about, so there is no "Web App", per say.

I agree, something else is installed on this system that requires PHP53 and is also requiring PHP 5.2, that is the problem; I have tried removing PHP53 and going with PHP 5.2, same problem as if I try to remove PHP 5.2 and installing PHP53, so its not possible to install Virtualmin on this server.

Just to be clear about what I'm asking about, I have a system, that for what ever reason, it wants to have php53 installed, even though I can completly remove php using
yum erase php*
and according to the system, its removed, so you would think yum does not have any dependancies for php, or it would try to remove those apps as well, unless something is wrong in this system, so how do we determine that, I don't know, so how do we work around it, well, in this case its CentOS, and it uses this line:

rhdeps=...php php-domxml php-gd php-imap php-mysql php-odbc php-pear php-pgsql php-snmp php-xmlrpc php-mbstring...

now it seems to me that if we add an Argument like:
--php53

we could do this:

add an argument to your case for --php53
around line 57

while [ "$1" != "" ]; do
case $1 in
...
;;
--php53)
php="php53"
...
esac
shift
done

if [ "$php" = "php53" ]; then
rhdeps=...php53 php53-gd
else
rhdeps=...php php-gd
fi

wget -O install.sh http://software.virtualmin.com/cgi-bin/install.cgi?serial=XXXX\&key=XXXX; /bin/sh install.sh --php53

Now I should be able to install this script, since its not forcing me to install both PHP 5.2, and PHP53, lets face it, when 5.4 comes out, then what will you do, this is getting crazy, all I'm asking for is a way around this issue, since it has me at a stand still.

Regardless of why this system wants to install PHP53, this line "rhdeps=...php php-gd" is causing it to install PHP 5.2 at the same time, which isn't going to happen on this system, or any others that require PHP53; but this code change should fix that; its ease and fast to fix.

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Fri, 02/17/2012 - 11:08
andreychek

Oh I see, we're talking about different Install Scripts.

I was thinking that you meant you were using Virtualmin's Install Script feature from within it's GUI to install a web application.

But you're actually performing a Virtualmin installation, using the install.sh installer.

Okay, now we're on the same page :-)

Virtualmin doesn't have a dependency for php53, only php... so the key would be for us to figure out what's installed that is generating that dependency.

Once you get Virtualmin up and running, it's no problem to replace php with php53.

So, you've erased everything beginning with "php-", that's good.

Can you verify that the same is true with "php53-" -- you shouldn't have any packages on your system beginning with that.

Also, you may want to verify that you don't have any third party repositories enabled. I'm not aware of any packages in a typical CentOS install that would require php53, but if a third party repository were enabled, that could have something that could be causing such a problem.

-Eric

Fri, 02/17/2012 - 13:09 (Reply to #9)
jflesher

Just to be clear:

yum erase php*

It removes both php and php53, it did so with no dependencies being removed, meaning there wasn't any, because if Virtalmin was installed, or another app that required php53, then it would have prompted to remove those apps as well, in other words: just what you would expect yum to do, which was my point, I do not have any Dependencies for php53 on this system, which leads me to believe that something in the VM install script does.

I noticed that no where in the install script dose it install php53, so the dependency is coming from somewhere else, now if you add the switch I suggested, even if you do not support it from a repos standpoint, its up to the user that uses this switch to install php53, have a system repos to pull from, which is in my case CentOS 5.7, unless they are in your repos, because I do not have any third party repos, least that I can see, I can attach the files below, so we can look into this more if you like, but I feel that the idea of the code I presented could be implemented today, without effecting the install, since it will only be activated if the argument is provided, and all that switch will do, is use the reference to php53 instead of php, so there is no way these changes could break an install, unless a user passes in the argument and dose not have php53 in any repo, but the failure message would reflect that, and this case is easy to correct, add a repos or do not use the argument.

This is CentOS 5.7, but only PHP 5.1 seems to be in their repos, (it may have php53 as well, that is my understanding, but not php53u), bleeding edge fixed that, but I did not install it till after I had this issue, it was in hope that it would fix this problem

Here are the Repos I have installed

# ls -l /etc/yum.repos.d

CentOS-Base.repo
CentOS-Debuginfo.repo
CentOS-Media.repo
CentOS-Vault.repo
virtualmin-bleed.repo
virtualmin.repo

Unless something in the Virtalmin install script has a dependency for php53, there is but one conclusion I could draw, that yum is not tracking the dependency for php correctly, since in CentOS for version 5.7 repos, there is php 5.1 and 5.3 (it looks like they skipped 5.2), so it defaults to the latest, which is php53, now the Virtalmin install script implicitly installs 5.1 or 5.2 via yum install php, where php is anything up to 5.3, where for some reason, they abandon all reasoning and went with another naming convention that would allow them to run both php and php53, which in reality does not work by default, and is a bad idea in any event, so lets keep in mind that this is the reason we are having this problem to begin with, so the only way to correct this problem is to make the fix I have suggested, so at this point, I need to make this a feature request or a bug report, and I have to go with the Bug, I can not install this script, under this situation, for what ever reason, so its a bug..

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Fri, 02/17/2012 - 13:34
andreychek

I do not have any Dependencies for php53 on this system, which leads me to believe that something in the VM install script does.

A new installation of Virtualmin on CentOS 5 does not install php 5.3, or any packages that require it.

If it did, the forums and bug tracker would be littered with people who have the same problem as yourself; but you're the first one to bring up this issue :-)

now if you add the switch I suggested, even if you do not support it from a repos standpoint, its up to the user that uses this switch to install php53

I'm not sure whether we'd support such a switch -- especially since most new CentOS installs are on CentOS 6, which only offers one PHP version. It's also rare that a distribution supports two PHP versions like CentOS 5 does. And in most cases, it's fairly straight to install php 5.3 on CentOS 5. We'll certainly give it some thought though. But even if we did, such a change wouldn't happen overnight, so we're going to need to find an alternative way to get this fixed for you :-)

The issue you're running into is a-typical, something unusual is going on with your setup that hasn't occurred elsewhere.

now the Virtalmin install script implicitly installs 5.1 or 5.2 via yum install php, where php is anything up to 5.3, where for some reason, they abandon all reasoning and went with another naming convention that would allow them to run both php and php53

Actually, the way they handled this was well thought out :-)

The issue they were trying to solve is that PHP 5.3 breaks a lot of things that work in PHP 5.1.

However, since CentOS 5 is now aging, many web apps no longer function on PHP 5.1.

So they wanted to offer a way to allow people to migrate to PHP 5.3 if they wanted to; but, by default, users would remain on PHP 5.1.

That's the reason for the different package names :-)

It's not possible to run both PHP 5.1 and PHP 5.3 using those packages, they designed it so that you have to choose one or the other.

so the only way to correct this problem is to make the fix I have suggested, so at tYouhis point, I need to make this a feature request.

Well, I disagree with that conclusion :-)

Since Virtualmin doesn't require PHP 5.3, the key is to determine what's generating such a requirement, and to disable it.

This problem doesn't occur on a freshly installed CentOS 5 system... so we need to figure out what is generating the problem, and to correct it.

I might suggest disabling all the repositories but that CentOS Base repository, and then attempting your installation again.

However, it doesn't really appear that this is a fresh CentOS 5 install. Is performing a fresh installation an option? As that may resolve your issue. Also, while CentOS 5 should certainly work (and we'll gladly help you get things up and running) -- had you considered CentOS 6, which comes with PHP 5.3.3 by default?

-Eric

Sun, 02/19/2012 - 20:06 (Reply to #11)
jflesher

Just to let you know, Virtualmin installed fine, it turns out this was just a warning, its working fine, I tried to pull up the link and it came up, I setup the sites, I don't know what else to say.

I still think my way will work fine and cause no issues, it would keep people from having to upgrade to php53, but at this point, I don't care, I'm back up and I thank you for your help, now that I know this, its not really an issue, but the messages below would not lead me to believe this.

Update: It did rename the repos, so I renamed it.

This was the begining of the Error message that lead me to believe it didn't install:

Resolving Dependencies
--> Running transaction check
---> Package php53-xml.x86_64 0:5.3.3-1.el5_7.6 set to be updated
--> Processing Dependency: php53-common = 5.3.3-1.el5_7.6 for package: php53-xml
--> Running transaction check
---> Package php53-common.x86_64 0:5.3.3-1.el5_7.6 set to be updated
--> Processing Conflict: php53-common conflicts php-common
--> Finished Dependency Resolution
php53-common-5.3.3-1.el5_7.6.x86_64 from updates has depsolving problems
--> 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
FATAL - 2012-02-17 14:23:20 - Fatal Error Occurred: Something went wrong during installation: 0
FATAL - 2012-02-17 14:23:20 - Cannot continue installation.
FATAL - 2012-02-17 14:23:20 - Attempting to remove virtualmin repository configuration, so the installation can be.
FATAL - 2012-02-17 14:23:20 - re-attempted after any problems have been resolved.
FATAL - 2012-02-17 14:23:20 - Removing temporary directory and files.
FATAL - 2012-02-17 14:23:20 - If you are unsure of what went wrong, you may wish to review the log
FATAL - 2012-02-17 14:23:20 - in /root/virtualmin-install.log

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Mon, 02/20/2012 - 09:09
andreychek

This was the begining of the Error message that lead me to believe it didn't install:

Yeah, that's a fatal error... if you get that, it certainly shouldn't be continuing.

However, if things are working for you, I won't complain :-)

Though I will do some tests on the new version of CentOS to see if I can find a way to trigger any of those messages.

Thanks for all the info!

-Eric

Mon, 02/20/2012 - 20:43
jflesher

Now I get this error when restarting the System, the Apache Web server will not start:

Syntax error on line 2055 of /etc/httpd/conf/httpd.conf: Invalid command 'FcgidMaxRequestLen', perhaps misspelled or defined by a module not included in the server configuration

This is the line FcgidMaxRequestLen 1073741824

I did have this working, no idea why its broke today.

my guess would be mod_fcgid was not loaded, but I show this being installed: mod_fcgid.x86_64 2.2-11.el5

but I can not get php to load, without the error I described in this thread with PHP53, so my question is what is causeing this issue with php, how can I get php 5.2 to install, or should I install php53, if so how.

Currently this is what it shows as install:

php x86_64 5.2.17-1.el5.vmbleed
php-cli x86_64 5.2.17-1.el5.vmbleed
php-common x86_64 5.2.17-1.el5.vmbleed
php-gd x86_64 5.2.17-1.el5.vmbleed
php-imap x86_64 5.2.17-1.el5.vmbleed
php-mbstring x86_64 5.2.17-1.el5.vmbleed
php-mcrypt x86_64 5.2.17-1.el5.vmbleed
php-mysql x86_64 5.2.17-1.el5.vmbleed
php-odbc x86_64 5.2.17-1.el5.vmbleed
php-pdo x86_64 5.2.17-1.el5.vmbleed
php-pear noarch 1:1.8.0-1.el5.vm
php-pgsql x86_64 5.2.17-1.el5.vmbleed
php-snmp x86_64 5.2.17-1.el5.vmbleed
php-xml x86_64 5.2.17-1.el5.vmbleed
php-xmlrpc x86_64 5.2.17-1.el5.vmbleed

Update: I just deleted FcgidMaxRequestLen, and it works fine, I thought this issue was fixed, my bad.

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Mon, 02/20/2012 - 22:48
andreychek

Howdy,

Do you know when that FcgidMaxRequestLen line had been added?

If I remember correctly, that syntax is for newer versions of FCGID -- versions that would be included with CentOS 6.

On older versions of FCGID (including what's available on CentOS 5), the syntax would be "MaxRequestLen".

-Eric

Mon, 02/27/2012 - 16:03
jflesher

Is there a way to reinsall this script without wiping out all the web sites I have setup, since I know went Live?

Keep in mind that your scipt will cause this php53 confilct, even though it has something to do with the template the ISP uses for this VPS account, changing ISP's, is something I hope to avoid till I get my Glass Connection, so I can go back to using my own servers and not have this issue.

I seem to be having other issues, and I'm only too fast at blaiming the install, since it did not finish without errors, and in this case those were fatal errors.

Now I'm having issues sending email.

Jeffrey Scott Flesher
Medically Retired Gulf War Vet

Mon, 02/27/2012 - 22:17
andreychek

Is there a way to reinsall this script without wiping out all the web sites I have setup, since I know went Live?

Re-running the installer is capable of causing problems if you have a live system... I wouldn't realy recommend that.

However, if you're having specific problems you'd like to try and tackle -- feel free to ask. I'd recommend opening up a new forum thread for new questions though, so that we don't end up with too many topics in this one thread :-)

-Eric

Topic locked