This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] fcgi-2.4.0-1


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.

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

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

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

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

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

I'm not sure /etc/defaults/ is appropriate for non /etc/ material. I'd
suggest installing the default website content in /usr/share/apache,
paralleling what I do for apache2.

> Or should I put the sample cgi's into /usr/share/apache2/cgi-bin/ ?

No, you should not. First, compiled code never belongs in /usr/share/.
Second, that directory is private to the apache2 package.

> Or into some /usr/share/fcgi/examples dir?

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

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

How is this relevant to the Cygwin package layout?

Max.



Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]