Request 867684 (accepted)

This request supersedes: request 867683 (Show diff)

Overview

Request 867684 accepted

- add conflicts with earlier versions of php (boo#1181292)
- update contents of configuration file (still referenced php7)
% mod_php8.conf
- require this PHP version of subpackages in Recommends/Suggests
- run apache-rex tests in php8:test as packages need to be build
first (otherwise tests run with previous version)

Created by adkorte almost 4 years ago
In state accepted
Supersedes 867683

Submit php8

Comments for request 867684 15

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

php7-json is still being obsoleted - intentional? (and other php7-FOO)

Arjen de Korte (adkorte) - almost 4 years ago

author source maintainer

Yes, the reason is explained in the comment (it is always build in, no longer configurable). I'm not sure what you mean by this, could you please elaborate?

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

as I wrote in the bug, the problem with an Obsoletes is that it fill be auto-picked by the solver as the better candidate.

Conflicts: might be more appropriate

Arjen de Korte (adkorte) - almost 4 years ago

author source maintainer

The Conflicts: php < %{version} (which is a Required: for all subpackages) will handle that as far as I can see. If a package requires php-json, this dependency can be satisfied by either php7-json or php8 (depending on which PHP version is used).

If you run zypper in php-json on a system where php7 is used, it will install php7-json and no attempt will be made to upgrade to php8. On a system where php8 is used it will just mention that it is already available through php8.

The actual problem boo#1181292 refers to, is not something we can solve. There are packages that don't handle the fact that there are now multiple PHP versions available well, because they have hard-coded php7 paths in them, although from an dependency point of view, they advertise they can use both. Either these packages should require php7 versions of capabilities they need, or be truly PHP version independent.

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

See for example this excerpt from a current openQA test:

# zypper -n --no-gpg-checks in apache2 /bin/hostname apache2-mod_php7 php7 php7-cli | cat; ( exit ${PIPESTATUS[0]} ); echo vn62i-$?-
Loading repository data...
Reading installed packages...
'apache2' is already installed.
No update candidate for 'apache2-2.4.46-13.1.i586'. The highest available version is already installed.
'/bin/hostname' not found in package names. Trying capabilities.
'hostname' providing '/bin/hostname' is already installed.
Resolving package dependencies...

The following 13 NEW packages are going to be installed:
  apache2-mod_php7 php7 php7-cli php8 php8-ctype php8-dom php8-iconv php8-openssl php8-pdo php8-sqlite php8-tokenizer php8-xmlreader php8-xmlwriter

so despite the 'user' explicitly asking for php7, php7-cli, apache2-mod_php7, php8 is being installed; which has the very negative side effect later on that I can't install php7-json anymore

so the main question here would be: why is php8 being pulled in?

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

zypper info --recommends php7

php7 itself should probably a bit clearer in recommendation

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

php8 does the same thing, for what it's worth

Anonymous User (_nobody_) - almost 4 years ago

This comment has been deleted

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

actually, my bad - the version is simply not there in the package in TW - that its only in the devel package...

Arjen de Korte (adkorte) - almost 4 years ago

author source maintainer

It is added to TW in this SR for php8 and will be in the SR for php-7.4.15 next week. But the Conflicts: php < %{version} in this SR should also prevent zypper from inintended upgrades from php7 to php8.

Arjen de Korte (adkorte) - almost 4 years ago

author source maintainer

Absolutely! This is already scheduled for the update to php-7.4.15 Thursday next week. If you prefer, I can push it through today however.

Arjen de Korte (adkorte) - almost 4 years ago

author source maintainer

This should no longer happen, now that we have Conflicts: php < %{version} in php8 (the very reason for this SR)

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

Yep - seems to be allright from first sight; let's see if we can convince openQA to also like it :)

if php7 comes already next week there is no reason to do the versioned recommends sooner - I would have rather written them as php7-FOO instead of php-FOO = version, but that's personal choice and both seem acceptable.

Thanks for your help and thoughts. I feel enlightened :)

Arjen de Korte (adkorte) - almost 4 years ago

author source maintainer

The reason why we (maybe it's just me) prefer the php-FOO = version over php7-FOO, is that it makes sure we get the actual version (and not an earlier one from a previous build) and that it is slightly easier when there is a major update of PHP. Although the latter can easily be worked around by using %{php_name}-FOO instead.

Do note that packages that depend on something from PHP should generally use php7-FOO, rather than php-FOO = version. The latter will depend on the monthly releases of PHP (and therefor, get rebuild/updated), while the first only on the major version. So if a package builds reproducibly, php7-FOO means it will not need to be updated monthly, while php-FOO = version will. Both is acceptable though (we provide the PHP version through the %{php_version} macro in php-devel).

Only if a package really doesn't depend on the PHP version, one might use php-FOO without version, but this seems to be pretty rare. Most packages will package files in PHP version dependent directories (ie, /usr/share/php7), so often this will lead to problems during installation, if the PHP version used during build is different from the version used for the installation.

Dominique Leuenberger (dimstar) - almost 4 years ago

reviewer

yep, personal taste; I don't mind which one you use.

As for other packages:

zypper se --requires php- can give a starting point what all requires php-*; they might be worthy to be checked and potentially be fixed; 2nd step would be to check the zypper se --recommends php- (in both cases, don't forget the trailing dash, to it's still part of the search string)