[ITP] fcgi-2.4.0-1

[Reini Urban]

Max Bowsher schrieb:
> Reini Urban wrote:
>> 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.
> 
> I don't understand this at all. *Lots* of non-enduser software is
> provided as DLLs.  I don't understand what you mean by "upgrades and
> conflict resolutions" in particular.
> 
> To my mind, a DLL is strongly preferable, because all packages using the
> library pick up any fixes automatically, instead of requiring a
> recompilation themselves.

fcgi does not build out of the box as shared library on any target. 
Almost no other distro has or uses the shared library.
So why should we?

In my reasoning which is unfortunately not english enough I also 
explained my private POV which makes sense at least to me.

>> 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
> 
> Sorry, but the above is entirely wrong. mod_fastcgi does not use libfcgi
> at all.

Sorry, but the above is entirely wrong. mod_fastcgi does use libfcgi as 
silent build requirement, and is not listed in the reqs because it is 
linked statically. Which is my point. Same for most other packages.

>> 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.
> 
> What are you trying to say? The above paragraph isn't meaningful English.

Sorry. My native lingua is german.

>> 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.
> 
> The above paragraph makes no sense, too.

> /var/www/ is not a natural location, in my opinion. It is certainly NOT
> a good location on Cygwin to install anything that is
> webserver-agnostic, as it has a long tradition of being associated with
> the Apache 1.3 package. The latest FHS is fairly emphatic about service
> data belonging in /srv/, not /var/.

> Not /usr/share/. You should put them in /usr/lib/fcgi/examples/.

Ok. Done.

>> I usually run fcgi's and cgi's on win32-native apache2 and lighttpd.
> How is this relevant to the Cygwin package layout?

For that user scenario where native apache and/or cygwin lighttpd has to 
deal with a cygwin fcgi. fcgi upgrades and breakage are dependend on 
developers decisions only if linked statically.
-- 
Reini