[ITP] fcgi-2.4.0-1

[ITP] fcgi-2.4.0-1

[Reini Urban]

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]

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/

[-- Attachment #2: README --]
[-- Type: text/plain, Size: 4031 bytes --]

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
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/cover.htm
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/covera.gif
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/fastcgi.htm
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/img00001.gif
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/img00002.gif
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/img00003.gif
  /usr/share/doc/fcgi-2.4.0/html/fcgi-devel-kit.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-java.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-perf.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-perl.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-spec.html
  /usr/share/doc/fcgi-2.4.0/html/fcgi-tcl.htm
  /usr/share/doc/fcgi-2.4.0/html/omi-logo.gif
  /usr/share/doc/fcgi-2.4.0/html/overview.html
  /usr/share/doc/fcgi-2.4.0/html/www5-api-workshop.html
  /usr/share/man/man1/cgi-fcgi.1.gz
  /usr/share/man/man3/FCGI_Accept.3.gz
  /usr/share/man/man3/FCGI_Finish.3.gz
  /usr/share/man/man3/FCGI_SetExitStatus.3.gz
  /usr/share/man/man3/FCGI_StartFilterData.3.gz
  /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

------------------

Port Notes:

----------  fcgi-2.4.0-1 -----------
Initial cygwin release. (for clisp-2.39-1)

Cygwin port maintained by: Reini Urban <rurban@x-ray.at>
Please address all questions to the Cygwin mailing list at <cygwin@cygwin.com>

Re: [ITP] fcgi-2.4.0-1

[Max Bowsher]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [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

Re: [ITP] fcgi-2.4.0-1

[Max Bowsher]

[-- Attachment #1: Type: text/plain, Size: 4798 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [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

Re: [ITP] fcgi-2.4.0-1

[Max Bowsher]

[-- Attachment #1: Type: text/plain, Size: 3646 bytes --]

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

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

[ITP] fcgi-2.4.0-2

[Reini Urban]

[-- Attachment #1: Type: text/plain, Size: 4763 bytes --]

Following the discussion with Max, I got persuaded to do the shared lib 
also. It required only the typical AM_LDFLAGS=-no-undefined,
and some praying and hackery, that the PATH within libtool install will 
not be exhausted to build the examples binaries.

So please consider the following new files:

http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2-src.tar.bz2
http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2.tar.bz2
http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/setup.hint
http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/libfcgi0-2.4.0-2.tar.bz2
http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/setup.hint
http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/libfcgi-devel-2.4.0-2.tar.bz2
http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/setup.hint


Max Bowsher schrieb:
> 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=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.
> 
> 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.

So it includes a static version.

I said most packages have no dependency for a shared libfcgi, besides 
debian.

>>>> 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.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

[-- Attachment #2: README --]
[-- Type: text/plain, Size: 5139 bytes --]

fcgi
------------------------------------------
FastCGI A High-Performance Gateway Interface.

Static library and a cgi-wrapper to create fastcgi enabled applications. 
End users will most likely not need that.
FastCGI is a fast, open, and secure Web server interface that
solves the performance problems inherent in CGI without introducing
any of the new problems associated with writing applications to
lower-level Web server APIs. Modules to support FastCGI can be plugged
into Web server APIs such as Apache API, NSAPI, and ISAPI.

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
  /usr/src/libfcgi0-<VERSION>-<CYGREL>.tar.bz2
  /usr/src/libfcgi-devel-<VERSION>-<CYGREL>.tar.bz2

Or use 'cygport fcgi-<VERSION>-<CYGREL>.cygport prep' 
to get a patched source directory.

-------------------------------------------

Files included in the fcgi package:

  /usr/bin/cgi-fcgi.exe
  /usr/lib/fcgi/examples/authorizer.exe
  /usr/lib/fcgi/examples/echo-cpp.exe
  /usr/lib/fcgi/examples/echo-x.exe
  /usr/lib/fcgi/examples/echo.exe
  /usr/lib/fcgi/examples/log-dump.exe
  /usr/lib/fcgi/examples/size.exe
  /usr/lib/fcgi/examples/threaded.exe
  /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
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/cover.htm
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-prog-guide/covera.gif
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/fastcgi.htm
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/img00001.gif
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/img00002.gif
  /usr/share/doc/fcgi-2.4.0/html/fastcgi-whitepaper/img00003.gif
  /usr/share/doc/fcgi-2.4.0/html/fcgi-devel-kit.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-java.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-perf.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-perl.htm
  /usr/share/doc/fcgi-2.4.0/html/fcgi-spec.html
  /usr/share/doc/fcgi-2.4.0/html/fcgi-tcl.htm
  /usr/share/doc/fcgi-2.4.0/html/omi-logo.gif
  /usr/share/doc/fcgi-2.4.0/html/overview.html
  /usr/share/doc/fcgi-2.4.0/html/www5-api-workshop.html
  /usr/share/doc/fcgi-2.4.0/images/aplib-hd.gif
  /usr/share/doc/fcgi-2.4.0/images/divider.gif
  /usr/share/doc/fcgi-2.4.0/images/fcgi-hd.gif
  /usr/share/doc/fcgi-2.4.0/images/mail-hd.gif
  /usr/share/doc/fcgi-2.4.0/images/navbar.gif
  /usr/share/doc/fcgi-2.4.0/images/serv-hd.gif
  /usr/share/doc/fcgi-2.4.0/images/words-hd.gif
  /usr/share/man/man1/cgi-fcgi.1.gz
  /usr/share/man/man3/FCGI_Accept.3.gz
  /usr/share/man/man3/FCGI_Finish.3.gz
  /usr/share/man/man3/FCGI_SetExitStatus.3.gz
  /usr/share/man/man3/FCGI_StartFilterData.3.gz

Files included in the libfcgi0 package:
  /usr/bin/cygfcgi-0.dll
  /usr/bin/cygfcgi++-0.dll 

Files included in the libfcgi-devel package:
  /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

------------------

Port Notes:

----------  fcgi-2.4.0-2 -----------
added shared libraries
split into fcgi, libfcg0 and libfcgi-devel packages

----------  fcgi-2.4.0-1 (not released) -----------
Initial cygwin release. (for clisp-2.39-1)

Cygwin port maintained by: Reini Urban <rurban@x-ray.at>
Address all questions to the Cygwin mailing list at <cygwin@cygwin.com>

[GTG] Re: [ITP] fcgi-2.4.0-2

[Dr. Volker Zell]

>>>>> Reini Urban writes:

    > Following the discussion with Max, I got persuaded to do the shared
    > lib also. It required only the typical AM_LDFLAGS=-no-undefined,
    > and some praying and hackery, that the PATH within libtool install
    > will not be exhausted to build the examples binaries.

    > So please consider the following new files:

    > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2-src.tar.bz2
    > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2.tar.bz2
    > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/setup.hint
    > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/libfcgi0-2.4.0-2.tar.bz2
    > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/setup.hint
    > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/libfcgi-devel-2.4.0-2.tar.bz2
    > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/setup.hint

These are building fine from source. Packaging looks good too.

GTG
  Volker

Re: [GTG] Re: [ITP] fcgi-2.4.0-2

[Corinna Vinschen]

On Aug  7 21:54, Dr. Volker Zell wrote:
> >>>>> Reini Urban writes:
> 
>     > Following the discussion with Max, I got persuaded to do the shared
>     > lib also. It required only the typical AM_LDFLAGS=-no-undefined,
>     > and some praying and hackery, that the PATH within libtool install
>     > will not be exhausted to build the examples binaries.
> 
>     > So please consider the following new files:
> 
>     > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2-src.tar.bz2
>     > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2.tar.bz2
>     > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/setup.hint
>     > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/libfcgi0-2.4.0-2.tar.bz2
>     > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/setup.hint
>     > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/libfcgi-devel-2.4.0-2.tar.bz2
>     > http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/setup.hint
> 
> These are building fine from source. Packaging looks good too.

Thanks, uploaded.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat