zypper lu doesnt show php7 needed but zypper up installs it?

Hi,

We did some system maintenance yesterday and are trying to figure out how something slipped through our checks.

We have a SLES12SP1 server with the Web Scripting module added for php. We had php5 installed. On doing a zypper up 5 got removed and 7 got added.

Below is what repo’s the box has:

web002:~ # zypper lr

| Alias | Name | Enabled | GPG Check | Refresh

–±-------------------------------------------------------------------±------------------------------------±--------±----------±-------
1 | SMT-http_patchserver:SLE-Module-Legacy12-Pool | SLE-Module-Legacy12-Pool | Yes | (r ) Yes | No
2 | SMT-http_patchserver:SLE-Module-Legacy12-Updates | SLE-Module-Legacy12-Updates | Yes | (r ) Yes | Yes
3 | SMT-http_patchserver:SLE-Module-Web-Scripting12-Pool | SLE-Module-Web-Scripting12-Pool | Yes | (r ) Yes | No
4 | SMT-http_patchserver:SLE-Module-Web-Scripting12-Updates | SLE-Module-Web-Scripting12-Updates | Yes | (r ) Yes | Yes
5 | SMT-http_patchserver:SLE-SDK12-SP1-Pool | SLE-SDK12-SP1-Pool | Yes | (r ) Yes | No
6 | SMT-http_patchserver:SLE-SDK12-SP1-Updates | SLE-SDK12-SP1-Updates | Yes | (r ) Yes | Yes
7 | SMT-http_patchserver:SLES12-SP1-Pool | SLES12-SP1-Pool | Yes | (r ) Yes | No
8 | SMT-http_patchserver:SLES12-SP1-Updates | SLES12-SP1-Updates | Yes | (r ) Yes | Yes
9 | Various_php-applications_(SLE_12.1) | Various php-applications (SLE_12.1) | Yes | (r ) Yes | Yes

I would then expect to see that we need php7 by doing a lp or lu. Neither show we need it, so it never appeared on our custom web page (built from the lu/lp commands) which system owners review to see what will change on servers. We did do a manual zypper refresh.

web002:~ # zypper lp
Refreshing service ‘SMT-http_patchserver’.
Loading repository data…
Reading installed packages…
No updates found.

web002:~ # zypper lu
Refreshing service ‘SMT-http_patchserver’.
Loading repository data…
Reading installed packages…
No updates found.

Then doing an update it will do the removal of php5 and add7 …

web002:~ # zypper up
Refreshing service ‘SMT-http_patchserver’.
Loading repository data…
Reading installed packages…

The following 20 NEW packages are going to be installed:
apache2-mod_php7 php7 php7-ctype php7-curl php7-dom php7-gd php7-iconv php7-json php7-ldap php7-mbstring php7-mcrypt php7-mysql php7-openssl php7-pdo php7-sqlite php7-tokenizer php7-xmlreader php7-xmlwriter php7-zip
php7-zlib

The following 20 packages are going to be REMOVED:
apache2-mod_php5 php5 php5-ctype php5-curl php5-dom php5-gd php5-iconv php5-json php5-ldap php5-mbstring php5-mcrypt php5-mysql php5-openssl php5-pdo php5-sqlite php5-tokenizer php5-xmlreader php5-xmlwriter php5-zip
php5-zlib

20 new packages to install, 20 to remove.
Overall download size: 4.4 MiB. Already cached: 0 B. After the operation, 10.2 MiB will be freed.
Continue? [y/n/? shows all options] (y): n

Does anyone have any hints as to how to get zypper to show me that these patches were needed? I’ve tried various things but couldn’t find something that shows us what we want.

Thanks
Mike

  1. “zypper lp” doesn’t show it, because it is not a patch for php5. Patches are a certain class of updates that come in a special format.

  2. “zypper lu” doesn’t show it, because a version upgrade is typically not an update for php5 directly. Instead it’s an optional update, as if it was something completely new and unrelated, which is admittedly unfortunate.

The update from php5 to php7 is applied because zypper knows from the RPM meta data, that php7 obsoletes php5. This can be seen from the spec file:

conflicts with php5 and should replace it

Obsoletes: php < %{version}
Obsoletes: php5

No one wants to check all spec files for probable updates, that’s why there is actually a good way to find out what zypper might install with a “zypper up” or “zypper patch”. You can do a so-called dry-run with the option “-D” or “–dry-run”:

zypper up -D

or

zypper up --dry-run

This does the same like a “zypper up” until the point where it would ask if you want to install the proposed updates.

Many thanks for this information. It explains what we are seeing and as you said is unfortunate.
We may put in a few more checks into our reporting logic incase we have this again but seems an edge case and something we shouldn’t see too often I wouldn’t think.

[QUOTE=currin;34058]Many thanks for this information. It explains what we are seeing and as you said is unfortunate.
We may put in a few more checks into our reporting logic incase we have this again but seems an edge case and something we shouldn’t see too often I wouldn’t think.[/QUOTE]

Up to now it didn’t happen too often. But since we are more flexible with the Modules concept in adding newer versions more easily, I assume that this happens more often the older SLE 12 gets.