Overview
Request 866123 accepted
- add PHP version to Requires: and Recommends: to make sure the same
version is installed as used during packaging
- drop Requires: http_daemon (fixes boo#1180132) and Suggests: apache2
(which is already required though mod_php_any)
- Created by adkorte
- In state accepted
-
Package maintainers:
aeneas_jaissle and
lrupp
- Supersedes 866107
Request History
adkorte created request
- add PHP version to Requires: and Recommends: to make sure the same
version is installed as used during packaging
- drop Requires: http_daemon (fixes boo#1180132) and Suggests: apache2
(which is already required though mod_php_any)
lrupp accepted request
Ok: let's take it for now an enhance the package with sub-packages as next step. I'm not forwarding it to Factory right now to get the sub-packages included first.
Thanks for bringing it up, Arjen, and thanks to all others for the fruitful discussion!
I never needed that change. I really don't see the benefit here. I would love to hear more about the why
The package hardcodes php7, yet may be built with php8 as well. If you leave this as is, there is no guarantee that php-<whatever> will recommend the same PHP version as the package was built with. So the package may install files in a php7 directory, but all the required packages will be php8 versions. That doesn't fly. So if a package is built with php7 (or php8) it is safer to also install the php7 (or php8) versions of everything it depends on.
when you have php7 and php8 ... which one is taken for build ? undefined ... better is to find out when installing which php? is installed and placing files based on that info. I think this is the wrong approach
Which version is used for packaging is defined by the Project Config for Factory. Since there are many backwards incompatible changes in php8, we've decided to prefer php7 for now. But this can (and probably will) change some at a later time. That's why this SR determines the PHP version at build time and adjust the %{php_name} accordingly, so that once that change happens, the package will change the requirements at the same time.
It would of course be possible to determine this all at install time, but in that case this whole package becomes redundant. None of the packages in server:php:applications must be installed by installing RPM packages. This is a convenience mostly, by automatically selecting the right packages for you. For almost all packages here, RPM is most likely a dead-end, with upstream more and more switching to composer, which makes it both very hard to package for RPM and probably redundant as well.
Until we give up on packaging in RPM, we could at least attempt to provide the proper dependencies. This is what this SR does, nothing more. Try installing roundcubemail on a Tumbleweed system: it will fail to run without this SR, as most of the dependencies will select the php8 versions by default. That's why we need to explicitly select the php7 versions or migrate everything to php8.
I got it now. Thank you for detailed info and your effort. :-)
dropping Requires: http_daemon will result in not installing any webserver. neither nginx nor apache nor what else is providing 'http_daemon'. Anyway apache will be installed cause of 'apache2-mod_%{php_name}' which is the same as 'mod_php_any' was ...
The http_daemon is redundant here. The package requires mod_php_and (= apache2-mod_php7 or apache2-mod_php8) which in turn will install apache2-prefork and apache2. The change to 'apache2-mod_%{php_name}' is to make sure you get the version for PHP the package was built for, rather than depending on whatever is the most recent version on the system (see above).
I think we should split out some sub-packages (for apache2, nginx, maybe lighttpd and more_important: php-fpm) here, which bring a templated configuration for the webserver/fpm part with them. I agree with Ralf Lang here: https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/message/IESJFHQWUXR7YRSPCKUTHRAZXZMTZ4X4/
+1
@aeneas_jaissle, @lrupp: review reminder