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