Bug#627213: New virtual package(s) for different kinds of httpd (fastcgi etc)

[Jonathan Nieder <jrnieder@gmail.com>]

Hi again,

Jonathan Nieder wrote:
> Jérémy Lal wrote:

>> Some clarifications :
>> * setting up the fastcgi process itself is specific for each case,
>>   so it's the responsibility of the "client" package to declare what it depends on
>>   (php5-cgi, libfcgi-ruby, ...).
>> * most, if not all, servers provide a way to spawn the fastcgi process within the
>>   server, binding them to sockets and managing permissions, but httpd-fcgi should not mean that.
[...]
> Could you clarify this further?
>
> If I understand correctly, it is possible for a FastCGI application to
> run on a different machine than the corresponding web server.  Does
> this mean each webapp would be responsible for launching the FastCGI
> application by some privately determined means and should use
>
>	Recommends: httpd-fastcgi
>
> to ensure people can view it?  Is there some standardized
> configuration file a FastCGI app can use to launch only when needed,
> if the admin wants that (socket activation through xinetd-workalikes,
> I guess), or does the server have to be involved in that case?  And is
> there some standardized configuration file a FastCGI app can use to
> show up in the server, or does that require custom configuration?

It was drawn to my attention that this does not seem to have much to do
with introduction of the virtual package httpd-fcgi.  Actually I
respectfully disagree: a virtual package represents a standardized
interface that multiple packages can rely on (for example "mailx"
means when the package is installed, the mailx command can be used in
the ways explained by POSIX), and the goal of the above questions was
to figure out what that interface for httpd-fcgi is.

One possible answer to these questions is: "no, there is no
standardized configuration mechanism --- httpd-fcgi just means that
the server allows running FastCGI apps by some means documented at
/usr/share/doc/<server package name>/README.fastcgi, and some webapps
will have their own README.fastcgi instead of setting anything up
automatically".  That would be fine --- I do not mean to suggest we
should standardize on anything more if that's all there is.

Sorry for the lack of clarity.

Cheers,
Jonathan