[ITP] fcgi-2.4.0-1

[Reini Urban]

Max Bowsher schrieb:
> Reini Urban wrote:
>> I want to contribute and maintain the fastcgi library.
>> I compiled it just as static library, which is useful for apache2,
>> lighttpd, ruby, php and clisp. Maybe I might be persuaded to maintain a
>> dll (libfcgi0) also.
> 
> I do not see how it would be useful for apache2.
> 
> Why a static library? To gain the benefits of smaller overall package
> size, and of not needing to rebuild dependent packages to pick up new
> library versions, I'd suggest _only_ shipping a DLL.

Well I was toying with this plan also. But found out that linux packages 
don't use it.

fcgi is not a enduser package, only a developer library to enable 
several packages to cooperate in a different way, so I prefered to keep 
everything together and let packages link the lib statically.
This way upgrades and conflict resolutions only have to be made on 
protocol changes, not software upgrades.

Oops. So setup.hint should be changed to category: Devel
I've added that at
http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/setup.hint

E.g. mandrake, suse and PLD have their mod_fastcgi.so without libfcgi 
dependency, linked statically. debian's libapache2-mod-fastcgi_2.4.2 
also. mandrake's php-fgci also, all clisp's also.
haven't looked further.
http://rpmseek.com/rpm/php-fcgi-5.1.2-1mdk.i586.html?hl=de&cs=fcgi:PN:0:0:1:0:2604182

Say a standalone /usr/lib/apache2/mod_fastcgi.so for apache2-mod_fastcgi 
or /usr/lib/apache/mod_fastcgi.dll for apache-mod_fastcgi, without 
libfcgi0 require, talking to a fcgi enabled ruby, clisp or php.
clisp being the only cygwin package so far which actually has it enabled.

The other reason is this: I don't only develop on cygwin,
I also run business services like clisp or xapian and swish cgi's with 
cygwin1.dll, but I wouldn't bother to use the cygwin apache. For testing 
and development it's great, similar to postgresql.
So I don't want to mix a native apache-mod_fastcgi with a cygwin fcgi 
using a shared libfcgi0. Makes no sense.

>>   /var/www/fcgi-bin/authorizer.exe
>>   /var/www/fcgi-bin/echo-cpp.exe
>>   /var/www/fcgi-bin/echo-x.exe
>>   /var/www/fcgi-bin/echo.exe
>>   /var/www/fcgi-bin/log-dump.exe
>>   /var/www/fcgi-bin/size.exe
>>   /var/www/fcgi-bin/threaded.exe
> 
> In Cygwin, /var/www/ is owned by the Apache 1.3.x package.  Unless you
> are promoting an association with that specific webserver, I'd suggest
> putting these somewhere else.
> 
> If they DO stay here, then the Apache 1.3.x maintainer needs to fix the
> postinstall script to be tolerant of an already-existing /var/www/
> directory on initial installation - currently, the Apache 1.3.x package
> would fail to create its default document root, cgi-bin, and icons
> directories in this case.

I have other several cgi-bin's still to ITP which would go into this 
very /var/www/cgi-bin dir also, since this is the natural location, 
where people would expect them. websearch engines like swish++ and 
xapian-omega also install their cgi-bin's this dir. Several other 
helpers also.

Please Apache 1.3.x maintainer, don't fail on an existing 
/var/www/cgi-bin dir. This is not yours entirely!
Speaking about the /var/www.new/ and /etc/apache.new/ trick, which 
really should be using /etc/defaults/

Or should I put the sample cgi's into /usr/share/apache2/cgi-bin/ ?
Or into some /usr/share/fcgi/examples dir?

I usually run fcgi's and cgi's on win32-native apache2 and lighttpd.
-- 
Reini