Citeren Ralf Lang <lang@b1-systems.de>:
Am 23.01.2021 um 11:02 schrieb Arjen de Korte:
Citeren Ralf Lang <lang@b1-systems.de>:
Hi, I think this is only partly right. Packages should not have hard preference on a specific web server unless they are server modules.
Or provide configurations specifically for that webserver, preferably in a way that bundles these settings in a subpackage like https://en.opensuse.org/openSUSE:Packaging_PHP#Supporting_different_web_serv..., but that's also what you mention below, so I guess we can agree on that. Still, many packages currently requirering mod_php_any are indeed apache2 only and they should definitly have a hard dependency on that.
I agree, if it's mod_php_any then it's inherently apache as the only provider of mod_php runtime. However, I am not sure if there is so much software that really needs mod_php for technical reasons.
Not mod_php only, but definitly apache2 only. In many cases, upstream will only provide Apache configuration files. So in quite a number of packages in server:php:applications, it is assumed the webserver is Apache through a BuildRequires: apache2 (invariably to pull in the directories to put configuration files in). If then everything is packaged in one monolithic RPM package, that means that the package is Apache only. Or (slightly better) the Apache specific configuration files are put in a subpackage should have a Requires: apache2 line. [...]
And if I may open an entirely different can of worms, I am currently dropping pear support for "my" 100+ packages groupware blob, moving to composer and I have no real idea how I can deliver an rpm-based, distribution friendly product out of it. There's little guidance on how to package that.
I assume you mean the Horde packages here? I wouldn't be too heartbroken if we decided to just ditch *all* of them. I have attempted to maintain some of the dependent packages for php-pear-Horde*, but never got around of migrating the horde5* to php7. In the present state, none of them are installable anymore. I'm running Horde as well, but use PEAR at the moment. The only benefit I see in packaging everything in RPM, would be the automatic installation of non-Horde packages it relies upon. But in practice, in almost all distro's the RPM packages that provide Horde are either out-of-date or still require fiddling with the configuation files to make it work. I fear that attempting to package these PEAR packages really isn't worth the effort anymore.
I am really puzzled how the role of classic OS packaging is supposed to evolve wrt these trees of right-for-this app version requirements.
We have some packages that do that, an quite honestly, it isn't looking pretty. I have not made up my mind yet, but I think that once Horde switches to Composer, I almost certainly will use that, instead of RPM packages that attempt to package composer files.
But that's just backstory, I think it is perfectly valid to just say "this app wants a web server of any sort installed". Unless in the case of roundcube, it's even possible the PHP backend would run nicely with an apache/nginx on a DIFFERENT server. Which is a perfectly valid scaleout scenario, I believe.
Sure, but in that case it should also offer feature parity among those choices. So either not bundle any webserver specific configuration files at all or place them in subpackages. See above, feature parity among webservers is rare, given that many upstream packages only provide configuration files for one (often Apache).