tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Webserver users




----- 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



Home | Main Index | Thread Index | Old Index