Citeren Michael Ströder :

...

so this is already fixed. What is the exect problem with rouncubemail ?

Please re-read boo#1180132.

And Arjen has raised general objections against these Provides.

Indeed: packages almost never depend on a random webserver, in almost all cases there are webserver specific configuration files that need to be written (roundcubemail is no exception here). So although it may be tempting to require a 'generic' webserver and let the user choose which, unless you're only serving static HTML, this almost never is what you want. Or you need to prepare your package for this by putting webserver or PHP specific files in subpackages that depend on specific PHP versions or webservers. I also noticed a problem in the way we build roundcubemail now and I suspect this will be a problem with other packages as well. In order to start building extensions, php8 is now also in Factory (and Tumbleweed). This is a problem for packages that use the PHP version agnostic Requires/Recommends/Suggests (for instance, php-session). The intended use for these, was for cases where we want to determine during package build which PHP version is used, so we can upgrade to a newer PHP version by changing the Project Config which version is used. This allows to make this change in a single location, rather than in lots of individual packages. This now seems to backfire, as there are packages that use these also for Requires/Recommends/Suggests. When there is no choice, this will install the same version as used in the build. But if there are (like now) two versions available and the package *really* requires a specific one (because it expects files to be in certain locations), this can fail. So although the BuildRequires can (and should) still be using PHP version agnostic php-<whatever>, the Requires/Recommends/Suggests must depend on the PHP version used during the build. See https://build.opensuse.org/request/show/866107.

On 1/23/21 6:28 AM, Ralf Lang wrote:

Hi, I think this is only partly right. Packages should not have hard preference on a specific web server unless they are server modules. Production php should not be mod_php anyway but rather fcgi/fpm which works with different webservers just the same. as for web server config snippets or whole vhost configs, they should be offerings only and i do not even like them to be automatically live/active. Providing software to the right parts of fs, compatible to a distribution, and assuming how the user will run it are two different businesses.

Full ack! I also hate this pseudo config management done by some packages and I'd also mandate to use php-fpm for all PHP applications. Ciao, Michael.

Am 23.01.2021 um 11:02 schrieb Arjen de Korte:

Citeren Ralf Lang :

...

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.

...

Production php should not be mod_php anyway but rather fcgi/fpm which works with different webservers just the same.

+1

...

as for web server config snippets or whole vhost configs, they should be offerings only and i do not even like them to be automatically live/active.

+1

...

Providing software to the right parts of fs, compatible to a distribution, and assuming how the user will run it are two different businesses.

+1, but yet I also understand that people want to provide something that works out-of-the box.

I understand that. It's revolving around what a distribution should do and should not do. 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 am really puzzled how the role of classic OS packaging is supposed to evolve wrt these trees of right-for-this app version requirements. 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. Regards Ralf

-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Am 23.01.2021 um 12:10 schrieb Arjen de Korte:

Citeren Ralf Lang :

...

Am 23.01.2021 um 11:02 schrieb Arjen de Korte:

...

Citeren Ralf Lang :

...

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 have not submitted Horde to new Leap iterations for a while on purpose. They should have lived in s:p:a to be available but not gone into the proper distro with its patch-but-no-features approach during lifecycle. If they are in Leap, that's more or less a mistake on my side. The kind of commitment behind keeping them in the main distribution release is not really benefitial to the admin or end user. PEAR is more or less a dead platform.

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.

The real target for rpm packaging, in my eyes, is installation into environments cut off from internet access like corporate or institution DCs. However, that style of security is going out of fashion and even then, there's CIs which can easily provide install images or other forms of ready-made environments. The other way the RPMs were useful was 3rd party usage of a few select libraries, but this use case has long since wandered off to composer or github forks. One last use case would have been to use OBS' image building capabilities, but this also works with a CI-generated tgz containing all things set up. No need for RPM here, it just would have been handy to reuse if we had it.

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 agree. I have development builds of horde libs and apps ( https://github.com/maintaina-com ) which are more or less based on upstream git-master with some necessary changes. I build public containers and ready-to-run images https://github.com/orgs/maintaina/packages/container/package/containers%2Fgr... and even a barebone of a turnkey docker solution https://github.com/maintaina/deployments based on openSUSE - sorry if it feels like an ad campaign, it's not intended to be one. None of these steps would benefit from a semi-automated RPM packaging. The real value and benefit is when quality-gated, integration tested versions of the development libraries or the complete product are available. This is something which needs to be sorted out with upstream and basically hinges on the same resource constraints as a really curated RPM build.

...

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.

I tried to maintain a 100+ dependencies ruby tree for a not even very complicated product in the one-lib-at-a-time, globally installed libraries "distribution way" and it made me nuts and caused a lot of frustration and it never met the standards openSUSE's acceptance team would ask for. I agree, it's really not pretty and probably it's not even a good idea. But that's how a lot of applications in many languages look like today and I wonder what distributions should do about them. Should we accept internal dependency trees as long as they follow sane quality rules? Should such applications be strictly out of scope for distributions? I am still figuring what I think myself and most likely few would agree either way. ;) If we didn't have this pandemic I'd like to discuss this at some conference or other, preferably with other nice people and a lot of beer. I'm not the online conference type though.

...

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.

I'm not sure I agree here but I get what it's about. Let me explain. As an upstream, I would maybe just care for the one config file which I use to build my omnibus package and even only care for one flavor or distribution (say, some lts ubuntu, because more often than not it's not *SUSE). As an upstream, I may or may not accept submissions into my repo which target other web servers/runtimes. As a packager, I'd gladly accept SRs for other runtimes/webservers and react on tickets if they have any problems. But I only would actively work on, say, adding nginx because I like to use nginx myself. I would not feel thrilled to decide if I force apache upon every user of the package OR support each and every webserver which happens to arrive in the distro. If somebody steps up to provide a config for some new scenario, fine. SR welcome. With all the CI features in OBS and in SCM platforms, any contributor could make it easy for the key maintainers of the software to validate if the config for the webserver they don't much care about breaks and then they could look into it (or accept SRs from others).

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). Yes, parity is rare, as interest may be uneven and resources are unlimited. I just feel I should be able to run software with the webserver I like, if I know how to do it - and I should not be forced to install the other webserver I won't run just to install the software.

In the end, the people who DO maintain will make the decisions and that's a very good thing about openSUSE. I am just suggesting why I feel http_daemon might be good here... This has gotten too long, sorry. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537