Re: [ITP] fcgi-2.4.0-1
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=decs=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
Re: [ITP] fcgi-2.4.0-1
Reini Urban wrote: Max Bowsher schrieb: 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. OK, the fact that upstream does not is a fairly good reason. However, Debian does ship a shared library, so we would not be alone in doing so if we decided to. I suggest that if it is reasonably easy to get a DLL to build, then we should have a DLL, and no static library, in the distribution, because of the eased maintenance (dependencies always use the current library, not what was current when they were built). If, on the other hand, it is infeasibly difficult to get a DLL building, we could live with just a static library. 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=decs=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. Please go check your facts before you cast my words back at me. mod_fastcgi does *NOT* use libfcgi - a fact I have verified by building mod_fastcgi successfully, without having libfcgi installed 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. Sorry. My native lingua is german. That's fine, but could you try to rephrase what you are trying to say, since you obviously consider the underlying point to be important. 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. Please do try to clarify this, as well. I'm especially confused about how native-windows versions have any relevance to the Cygwin packaging. 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. Again, please clarify, I don't understand the problem here. To the best of my knowledge, FastCGI is a fixed and unchanging protocol - upgrades should be bugfixes only and should not cause breakage. Max. signature.asc Description: OpenPGP digital signature
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=decs=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. signature.asc Description: OpenPGP digital signature
[ITP] fcgi-2.4.0-1
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. What: http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-1-src.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-1.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/setup.hint Where else: http://search.rpmseek.com/search.html?cs=fcgi:PN Debian, Mandrake, ... Attached is the README with the full list. But, is this license compatible? To me it looks liberal enough. http://www.fastcgi.com/cvs/fcgi2/LICENSE.TERMS This FastCGI application library source and object code (the Software) and its documentation (the Documentation) are copyrighted by Open Market, Inc (Open Market). The following terms apply to all files associated with the Software and Documentation unless explicitly disclaimed in individual files. Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here. If modifications to this Software and Documentation have new licensing terms, the new terms must be clearly indicated on the first page of each file where they apply. OPEN MARKET MAKES NO EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE SOFTWARE OR THE DOCUMENTATION, INCLUDING WITHOUT LIMITATION ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL OPEN MARKET BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY DAMAGES ARISING FROM OR RELATING TO THIS SOFTWARE OR THE DOCUMENTATION, INCLUDING, WITHOUT LIMITATION, ANY INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES OR SIMILAR DAMAGES, INCLUDING LOST PROFITS OR LOST DATA, EVEN IF OPEN MARKET HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED AS IS. OPEN MARKET HAS NO LIABILITY IN CONTRACT, TORT, NEGLIGENCE OR OTHERWISE ARISING OUT OF THIS SOFTWARE OR THE DOCUMENTATION. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ fcgi -- FastCGI A High-Performance Gateway Interface This library builds only as static library so far. Runtime requirements: cygwin-1.5.20-1 or newer Build requirements: cygwin gcc-core automake autoconf binutils Canonical homepage: http://fastcgi.com/ Canonical download: http://fastcgi.com/dist/fcgi-2.4.0.tar.gz Build instructions: tar xfj fcgi-VERSION-CYGREL-src.tar.bz2 if you use setup to install this src package, it will be unpacked under /usr/src automatically cd /usr/src cygport fcgi-VERSION-CYGREL.cygport all This will create: /usr/src/fcgi-VERSION-CYGREL.tar.bz2 /usr/src/fcgi-VERSION-CYGREL-src.tar.bz2 Or use 'cygport fcgi-VERSION-CYGREL.cygport prep' to get a patched source directory --- Files included in the binary distribution: /usr/bin/cgi-fcgi.exe /usr/include/fastcgi.h /usr/include/fcgi_config.h /usr/include/fcgi_stdio.h /usr/include/fcgiapp.h /usr/include/fcgimisc.h /usr/include/fcgio.h /usr/include/fcgios.h /usr/lib/libfcgi++.a /usr/lib/libfcgi++.la /usr/lib/libfcgi.a /usr/lib/libfcgi.la /usr/share/doc/Cygwin/fcgi-2.4.0.README /usr/share/doc/fcgi-2.4.0/INSTALL /usr/share/doc/fcgi-2.4.0/LICENSE.TERMS /usr/share/doc/fcgi-2.4.0/README /usr/share/doc/fcgi-2.4.0/examples/authorizer.c /usr/share/doc/fcgi-2.4.0/examples/authorizer.mak /usr/share/doc/fcgi-2.4.0/examples/echo-cpp.cpp /usr/share/doc/fcgi-2.4.0/examples/echo-cpp.mak /usr/share/doc/fcgi-2.4.0/examples/echo-x.c /usr/share/doc/fcgi-2.4.0/examples/echo.c /usr/share/doc/fcgi-2.4.0/examples/echo.mak /usr/share/doc/fcgi-2.4.0/examples/echox.mak /usr/share/doc/fcgi-2.4.0/examples/log-dump.c /usr/share/doc/fcgi-2.4.0/examples/size.c /usr/share/doc/fcgi-2.4.0/examples/size.mak /usr/share/doc/fcgi-2.4.0/examples/threaded.c /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ap_guida.htm /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ap_guide.htm /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/apaman.htm /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ch1inta1.gif /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ch1intra.gif /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ch1intro.htm /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ch2c.htm /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ch3perl.htm /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/ch4tcl.htm
Re: [ITP] fcgi-2.4.0-1
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. /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. Max. signature.asc Description: OpenPGP digital signature
Re: [ITP] fcgi-2.4.0-1
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=decs=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
