[pkg-lighttpd] Bug#664997: Issues with your #664997 bug report

[Arno Töll]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 26.03.2012 00:29, Adrian Bunk wrote:
>>> So having libapache2-mod-php5 as first alternative in the
>>> dependencies is exactly correct.
>> 
>> It matches the guidelines, but maybe the guidelines aren't as
>> good as they should be. ;)
> 
> Personally I don't think your suggestion makes sense, but the
> guidelines are currently being discussed, so discuss it there and
> not in bugs for random packages...

I do not think I've written anything about programming language
dependencies in the packaging guidelines after all. That's probably
something which should be addressed on a per-language basis again.

Following our (i.e. Apache's) guidelines we appreciate any effort to
support web applications in an existing Apache environment. We provide
package maintainers a decent library of functions and programs to get
things in place. However, I am maintaining Lighttpd as well (Hello
Olaf!), thus I'm all open ears to get decent support of alternative
web servers in Debian. I was trying to push a web application policy
already and I contacted nginx maintainers on that (CC:-ed as well).
They all seemed interested to consolidate web application dependencies
into a uniform and predictable behavior.

My proposal from the packaging guidelines covers web server
dependencies in fair way I think. It does not force anyone to install
Apache who does not want to, but it recommends packagers to declare a
package relationship against a web server. That's a fair trade-off I
think, as its fairly straightforward to assume people who install a
web application want to run it on a web server. I do not think we need
to cope with corner and special cases - there is equivs for that, or
the fact the dependency can just be ignored when demoted to a
recommends. So, yes, if your web application ships a ready-to-use
configuration file for a given web server, it's perfectly legit to
recommend its use.

So, as a start, web applications should recommend a web server like
this if they ship both, an Apache2 configuration file and a Lighttpd
configuration file:

Recommends: apache2 | lighttpd | httpd

Of course, that's not enough to run for a PHP application. I was
outlining lots of ways to execute PHP scripts on a web server. I do
not see what's so bad to depend on libapache2-mod-php5 or whatever PHP
maintainers provide these days. Obviously a web application needs a
PHP interpreter at some point and that's a perfect use case for a
dependency. That's what they are for.

However, I can certainly imagine ways where such a dependency could be
satisfied by any web server supporting PHP by one way or another. What
about a httpd-php virtual package for example which could be provided
by a web server and enables a configuration in the web server ready to
execute PHP scripts?

For Apache, the libapache2-mod-php5 package could provide httpd-php
(among others, including FastCGI and FPM setups), for lighttpd we
would only need to set-up a running FastCGI + PHP-CGI environment at
postinst time, which is already mostly there, too. Likewise for nginx,
I guess. Then, PHP web applications could formulate dependencies like
this:

Depends: libapache2-mod-php5 | whatever-alternative-php5 | httpd-php

Now, people who would like to use Lighttpd instead of the default
Apache would only need to do a

apt-get install lighttpd the-web-app

and the httpd-php configuration package provided by Lighttpd would
enable an environment ready to run PHP. Note, my
"httpd-programming-language" approach has stronger implications than
the traditional "httpd-cgi" virtual packages which traditionally only
implied a "CGI capable web server". In my setup, a web server
providing it would actually need a working environment with a stable
interface, web application package maintainers could rely on.

Having that said, you can see on my CC:-orgy this discussion is
getting nowhere if we continue to spread it among dozens of people,
lists and bugs. Hence, please, let's pick a single list, start over
doing a clean proposal and see where things end up.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPb7A/AAoJEMcrUe6dgPNtCeoP/2bbjovSO+pch8eFTndeo8Mj
WNDdE2QIpA2wsr86JEHDExb7TvGznDcOyT2tHHT+9n3vSOhPdg5CATDS8lnQzZrS
GS8fXfUyPZn1XXcQy6NCobSw3DSdO18MmktqCAYsAmkpJW9GAKjO1mlPaQVTOwiN
7277fTK3Dq4oZmdZ0TlGRiR0tlIjGt6AKnMKUpiXyVCN4wwo+H5vrEHR4dMVswgA
8FSYJmsjK/k2LjxOf2C91jTyq0z5LdBz/gu6gwnZ36Ctskq0TA1zJKkqmFaB3bRA
S5BOsVixnJkleuI649mUUqs9ZxKPPWMVNOgJW9FdkHdXqO47u8m/h0qZfBCAZEKM
ppsFQbt25EOkI6jDHoR8jYRsqOKWIW4qL6CI2d3nRkYPr3mdDNBcIRm8o2j15ZFv
eLTznEyXMmz0bWl7CsBJxOU0QG14ukWfsGsv21outEVONjpZ480YxPqfpv9MZ8Ix
sYYHVJwt5K+KJg+5pX6ABkBt3RSpTd+vbZHbk+weqlVrR5O8qM6xWZchKYCsZD51
4xlNNeoVLZsA9YabYLL594PdrFuR17q3AGRVqQQjwvjjlySjPQ8kQbdplTDw6mHg
ARdIBfknMVbD/FwetMR6T/OAvMbdfcrCpLuOciiBhloW18Cg6TLfrETbYy/+Nziz
i+NVHeR05v09D/Lh9Bqp
=VZvv
-----END PGP SIGNATURE-----