----- Le 27 Avr 18, à 20:05, triaxx triaxx%triaxx.org@localhost a écrit : > Le 2018-04-27 15:28, Joerg Sonnenberger a écrit : >> On Fri, Apr 27, 2018 at 07:56:55AM +0200, Frédéric Fauberteau wrote: >>> >>> >>> Le 2018-04-26 22:13, Joerg Sonnenberger a écrit : >>> > On Thu, Apr 26, 2018 at 09:30:15PM +0200, triaxx wrote: >>> > > An ideal solution should be to have php applications depending on >>> > > either >>> > > apache + ap-php or nginx/lighttpd + php-fpm... But we don't have >>> > > dynamic >>> > > depencies yet. >>> > >>> > I'd prefer if they just depended on the php core language and left the >>> > choice of web server binding to the administrator. There are a variety >>> > of PHP supervisors for example, no need to wire anyone down. >>> >>> You're right. I just forget "e.g." :) >>> >>> Without dynamic dependencies, we could imagine a post-install script >>> that >>> interactively helps admin to install required dependencies, copy >>> config >>> files to the right places, init database... but it looks immoderate >>> for now >>> IMO. >> >> My point is that the web server <-> PHP binding is not a dependency of >> the application. Just like the X server is not a dependency of KDE. >> I don't think we need to provide a post-install script either. It's not >> like the admin doesn't need to customize things anyway, i.e. to specify >> how the PHP app is hooked into the vhost mapping etc. We don't need to >> do anything like that for Perl or Python based frameworks, so why >> should >> we have to do it for PHP? > > We don't have an intrusive package manager like Debian, so I totally > agree with you. But I think it is appreciable to have an application > that works out of the box. Because I don't use Apache (but nginx or > lighttpd), I try to find solutions to not have useless dependencies > installed. For now, a binary bulk does not fulfil. Hi, from what I see things : the web server <-> PHP binding => configuration (mostly) the PHP <-> web application binding => software dependency and, if needed, the web application <-> database binding => configuration (mostly) We could have some generic meta-packages to handle basic use-cases : * Apache + mod_php ; * Apache + php-fpm ; * Nginx + php-fpm ; * Lighthttpd + php-fpm. But that's already 4 meta-packages. Add php-pm when it's stable, or the good old php-fastcgi, and that's 6 more meta-packages. These packages are likely to include some default (and sane) configuration, which will need maintenance over time. After this, if I follow Frédéric's logic, there would be some more packages to handle the web application, let's take Wordpress for example : * Apache + mod_php + Wordpress (which already depends on some PHP extensions) ; * Apache + php-fpm + Wordpress ; * Nginx + php-fpm + Wordpress ; * Lighthttpd + php-fpm + Wordpress. And we would have 4 more meta-packages, maybe more. That brings the total to at least 8 meta-packages just to cover Wordpress use cases. That would be too much. It's 2018 : people use configuration management systems and automation tools to install a web server and its application(s). I'm in favor of removing any web server dependency (unless there is a good reason) from a web application. We could, as a courtesy and in order to help newcomers, add configuration snippets in the example directory. With some luck, some web application projects already provide them ! -- Nils Ratusznik https://LinuxFr.org https://NetBSD.org https://blog.anotherhomepage.org
Attachment:
signature.asc
Description: OpenPGP digital signature