Topic: [SOLVED] libwebp dependency prevents CentOS 6 update

[Jean-Philippe Pialasse]

Mark,

after you disable the remi repo  ( and keep it for manually and independently update php56 which you use), I feel like the update should run fine.

However, it might occurs that you already have installed previously some package that should not have been, hence leaving an error trying to update. If so, just send us the following :

Code: [Select]

/sbin/e-smith/audittools/newrpms|grep remithis will allow to find non base rpm


as a reference, my SME9 with php-scl installed will return this :

Code: [Select]

# /sbin/e-smith/audittools/newrpms|grep remi
gd-last.x86_64                     2.2.1-2.el6.remi          @remi
libzip-last.x86_64                 1.1.3-1.el6.remi          @remi
php54.x86_64                       2.1-4.el6.remi            @remi
php54-php.x86_64                   5.4.45-9.el6.remi         @remi
php54-php-bcmath.x86_64            5.4.45-9.el6.remi         @remi
php54-php-cli.x86_64               5.4.45-9.el6.remi         @remi
php54-php-common.x86_64            5.4.45-9.el6.remi         @remi
php54-php-enchant.x86_64           5.4.45-9.el6.remi         @remi
php54-php-gd.x86_64                5.4.45-9.el6.remi         @remi
php54-php-imap.x86_64              5.4.45-9.el6.remi         @remi
php54-php-ldap.x86_64              5.4.45-9.el6.remi         @remi
php54-php-mbstring.x86_64          5.4.45-9.el6.remi         @remi
php54-php-mysqlnd.x86_64           5.4.45-9.el6.remi         @remi
php54-php-pdo.x86_64               5.4.45-9.el6.remi         @remi
php54-php-pear.noarch              1:1.10.1-4.el6.remi       @remi
php54-php-pecl-zip.x86_64          1.13.2-1.el6.remi         @remi
php54-php-process.x86_64           5.4.45-9.el6.remi         @remi
php54-php-soap.x86_64              5.4.45-9.el6.remi         @remi
php54-php-tidy.x86_64              5.4.45-9.el6.remi         @remi
php54-php-xml.x86_64               5.4.45-9.el6.remi         @remi
php54-runtime.x86_64               2.1-4.el6.remi            @remi
php55.x86_64                       2.1-5.el6.remi            @remi
php55-php.x86_64                   5.5.36-1.el6.remi         @remi
php55-php-bcmath.x86_64            5.5.36-1.el6.remi         @remi
php55-php-cli.x86_64               5.5.36-1.el6.remi         @remi
php55-php-common.x86_64            5.5.36-1.el6.remi         @remi
php55-php-enchant.x86_64           5.5.36-1.el6.remi         @remi
php55-php-gd.x86_64                5.5.36-1.el6.remi         @remi
php55-php-imap.x86_64              5.5.36-1.el6.remi         @remi
php55-php-ldap.x86_64              5.5.36-1.el6.remi         @remi
php55-php-mbstring.x86_64          5.5.36-1.el6.remi         @remi
php55-php-mysqlnd.x86_64           5.5.36-1.el6.remi         @remi
php55-php-pdo.x86_64               5.5.36-1.el6.remi         @remi
php55-php-pear.noarch              1:1.10.1-4.el6.remi       @remi
php55-php-pecl-jsonc.x86_64        1.3.9-1.el6.remi          @remi
php55-php-pecl-zip.x86_64          1.13.2-1.el6.remi         @remi
php55-php-process.x86_64           5.5.36-1.el6.remi         @remi
php55-php-soap.x86_64              5.5.36-1.el6.remi         @remi
php55-php-tidy.x86_64              5.5.36-1.el6.remi         @remi
php55-php-xml.x86_64               5.5.36-1.el6.remi         @remi
php55-runtime.x86_64               2.1-5.el6.remi            @remi
php56.x86_64                       2.1-5.el6.remi            @remi
php56-php.x86_64                   5.6.22-1.el6.remi         @remi
php56-php-bcmath.x86_64            5.6.22-1.el6.remi         @remi
php56-php-cli.x86_64               5.6.22-1.el6.remi         @remi
php56-php-common.x86_64            5.6.22-1.el6.remi         @remi
php56-php-enchant.x86_64           5.6.22-1.el6.remi         @remi
php56-php-gd.x86_64                5.6.22-1.el6.remi         @remi
php56-php-imap.x86_64              5.6.22-1.el6.remi         @remi
php56-php-ldap.x86_64              5.6.22-1.el6.remi         @remi
php56-php-mbstring.x86_64          5.6.22-1.el6.remi         @remi
php56-php-mysqlnd.x86_64           5.6.22-1.el6.remi         @remi
php56-php-pdo.x86_64               5.6.22-1.el6.remi         @remi
php56-php-pear.noarch              1:1.10.1-4.el6.remi       @remi
php56-php-pecl-jsonc.x86_64        1.3.9-1.el6.remi          @remi
php56-php-pecl-zip.x86_64          1.13.2-1.el6.remi         @remi
php56-php-process.x86_64           5.6.22-1.el6.remi         @remi
php56-php-soap.x86_64              5.6.22-1.el6.remi         @remi
php56-php-tidy.x86_64              5.6.22-1.el6.remi         @remi
php56-php-xml.x86_64               5.6.22-1.el6.remi         @remi
php56-runtime.x86_64               2.1-5.el6.remi            @remi
Unless you have other packages voluntary isntalled from remi repo (phpmyadmin...) any package not in the list should be reversed to its base version, with only the base repo installed you could run

Code: [Select]

yum downgrade packagename

[Mophilly]

Thank you, RequestedDeletion, janet and Jean-Philippe.

One difference between the list provided by Jean-Philippe and my installation is the inclusion of pgsql. For each of the remi php collections, I have added pgsql, e.g. php54-php-pgsql.x86_64, 5.4.45-8.el6.remi, and php55 and php56.

Another difference is the version numbers. For example, in the php54 collection I have version 5.4.45-8.el6.remi while the same packages in Jean-Philippe's list are 5.4.45-9.el6.remi. Note the delta of version -8 and -9. Other packages have a similar relationship. My system has an earlier php55 package, 5.5.35-1.el6.remi, while Jean-Philippe's contains 5.5.36-1.el6.remi.

It appears, then, that I need to update my remi installations. I will disable the remi repo and run the update again. If that works as desired, I will attempt the update for remi.

[Mophilly]

I ran the following:

Code: [Select]

db yum_repositories setprop remi status disabled
signal-event yum-modify
yum update
signal-event post-upgrade; signal-event reboot
The yum update terminated normally. Server booted up and appears to be functioning normally. However, the server-manager panel reports that updates are available. The list of updates appears to be the same packages as was processed by the manual update.

Would running the update again from server-manager be an appropriate action?

[guest22]

I ran the following:

The yum update terminated normally. Server booted up and appears to be functioning normally. However, the server-manager panel reports that updates are available. The list of updates appears to be the same packages as was processed by the manual update.

Would running the update again from server-manager be an appropriate action?

The server-manager checks for updates once a day and sets a flag. You've beaten the server-manager by upgrading manually, so the flag is not set back yet. Check in a day again, or force in server-manager to check for updates.

[Mophilly]

Thank you, RequestedDeletion.

You wrote "or force in server-manager to check for updates". What control in server-manager would instigate this "forcing"? Run the "software installer" once more or something else?

[guest22]

Software installer -> change settings -> change nothing -> save

[Mophilly]

That worked. Many thanks, again. 

I am off to the php-scl update.

[Mophilly]

To recap this thread...

The CentOS updates were applied correctly once I disabled the remi repo in the SME db. For the new reader, the enabled repo's listed in the SME db should be limited to only those that are part of the standard distribution. Be mindful of this if and when you elect to add other packages.

Following that I ran the smeserver-php-scl update from smecontribs. That completed normally, with nothing in the log that seemed out of the ordinary.

I cannot yet update the packages from remi. The package gd-last-2.2.1-2.el6.remi.x86_64 has a dependency on libwebp.so.5. More on that after further investigation.

[Jean-Philippe Pialasse]

Considering this https://pkgs.org/search/Libwebp

I would say

Code: [Select]

yum update php56 --enablerepo=remi,epel

[Mophilly]

Thank you, Jean-Philippe.

Running the update for php56 did not provide a new result. It boils down to the gd-last package.

Code: [Select]

# yum update gd-last --enablerepo=remi,epel
...
Resolving Dependencies
--> Running transaction check
---> Package gd-last.x86_64 0:2.1.1-2.el6.remi will be updated
---> Package gd-last.x86_64 0:2.2.1-2.el6.remi will be an update
--> Processing Dependency: libwebp.so.5()(64bit) for package: gd-last-2.2.1-2.el6.remi.x86_64
--> Finished Dependency Resolution
Error: Package: gd-last-2.2.1-2.el6.remi.x86_64 (remi)
           Requires: libwebp.so.5()(64bit)

I could not find a reference to libwebp in epel that appeared to match the error report.

[guest22]

Running the update for php56 did not provide a new result. It boils down to the gd-last package.

Code: [Select]

# yum update gd-last --enablerepo=remi,epel


1. You entered gd-last as package name, where as it was suggested to enter php56 as package name
2. You have not added the epel repo to you yum repositories (see wiki)

Try 'yum update php56 --enablerepo=remi --enablerepo=epel' and you will see the epel repo is unknown. Unless you already added it after posting your yum repositories.

[Mophilly]

Thank you, RequestedDeletion. I appreciate the assistance and I am sorry this is dragging on so long.

Regarding item 1, while it is true that my example referenced gd-last, I did run yum update for php56 as suggested before running the same command for gd-last.

Regarding item 2, you were correct. The epel repo was not part of the yum meta data although it was listed in the yum directory tree. I updated the yum data per the wiki. I followed that with "signal-event yum-modify", then "yum clean all --enablerepo=*" and epel is now listed (as disabled) when I run "db yum repositories show".

When I ran "yum update php56 --enablerepo=remi --enablerepo=epel" once more, yum reported that no packages are marked for update. The output of "yum list installed" shows the php54, php55 and php56 packages in red, which I assume means they should be updated. (As an aside, I also noted that webtatic 6-5 is in the same state although I don't recall specifically adding that package.)

Earlier in this thread it was suggested to use "yum downgrade <package name>". The versions of the php packages installed for smeserver-php-scl are older than those shown in Jean-Phillipe's example in this thread. So downgrade doesn't seem like the action to take now. The result of "yum update --enablerepo=smecontribs smeserver-php-scl" the result is also "no packages marked for update", although the yum update was also run yesterday and updates were applied. 

Questions: would the update of smeserver-php-scl normally include the php packages? If yes, should I "downgrade" smeserver-php-scl and run update for it again?

Suggestions are most welcome.

[Jean-Philippe Pialasse]

Thank you, RequestedDeletion. I appreciate the assistance and I am sorry this is dragging on so long.

Regarding item 1, while it is true that my example referenced gd-last, I did run yum update for php56 as suggested before running the same command for gd-last.

Regarding item 2, you were correct. The epel repo was not part of the yum meta data although it was listed in the yum directory tree. I updated the yum data per the wiki. I followed that with "signal-event yum-modify", then "yum clean all --enablerepo=*" and epel is now listed (as disabled) when I run "db yum repositories show".

When I ran "yum update php56 --enablerepo=remi --enablerepo=epel" once more, yum reported that no packages are marked for update. The output of "yum list installed" shows the php54, php55 and php56 packages in red, which I assume means they should be updated. (As an aside, I also noted that webtatic 6-5 is in the same state although I don't recall specifically adding that package.)

Earlier in this thread it was suggested to use "yum downgrade <package name>". The versions of the php packages installed for smeserver-php-scl are older than those shown in Jean-Phillipe's example in this thread. So downgrade doesn't seem like the action to take now. The result of "yum update --enablerepo=smecontribs smeserver-php-scl" the result is also "no packages marked for update", although the yum update was also run yesterday and updates were applied. 

Questions: would the update of smeserver-php-scl normally include the php packages? If yes, should I "downgrade" smeserver-php-scl and run update for it again?

Suggestions are most welcome.

then the full step would be

Code: [Select]

yum update php54* php55* php56* --enablerepo=remi,epel

[Mophilly]

Bingo! That worked.

Thank you, Jean-Philippe, and RequestedDeletion, janet and Stephano for the help on this issue.

[Jean-Philippe Pialasse]

I took the liberty to document this : https://wiki.contribs.org/PHP_Software_Collections#Update