Re: towards a 2.07 release
On 2005/10/03 04:59, Joe Schaefer <[EMAIL PROTECTED]> wrote: > Note this is our first non-dev candidate, so please give it the > extra scrutiny it deserves. Release Candidate #1 - All tests pass on Debian Sid/ppc64 and Debian Etch/amd64 (both pure64). Max
Re: Session/Cookie-Based Authentication Library
On 2005/09/22 14:11, Eli Marmor <[EMAIL PROTECTED]> wrote: > By the way: it may be based on libapreq2. And if I come into it, > then what about the following idea: to add some authentication > functions to libapreq2; In any case, it already does most of the > work, including GET/POST parameter manipulation, as well as cookie > manipulation. I believe we should not add anything about authentication to libapreq. It is currently a generic request parser, and should stay so. Adding authentication would require to make assumptions about the authentication procedure, which in turn forces users to follow our assumptions. There is no disadvantage in implementing authentication in an additional library. Max
Re: Build error on FreeBSD-5.4
On 2005/08/29 14:46, Nikolay Ananiev <[EMAIL PROTECTED]> wrote: > This is the error I get when I run make (this happens on freebsd 5.2 too) > > ar cru .libs/mod_apreq2.a handle.o filter.o > ranlib .libs/mod_apreq2.a > creating mod_apreq2.la > (cd .libs && rm -f mod_apreq2.la && ln -s ../mod_apreq2.la mod_apreq2.la) > make: don't know how to make all-local. Stop > *** Error code 1 please try with GNU make. Max
Re: Bug#321955
On 2005/08/13 00:42, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > BTW, I wasn't really aware that there _were_ that many ways to use > libapreq2. If there are useful ones which for some reason aren't > supported by my packaging, I'd be happy to hear about them. libapreq can be used for request parsing in: - CGI programs written in C - CGI programs written in Perl - Apache 2 C modules - Apache 1 C modules - mod_perl 2 request handlers - more libapreq2 bindings will be added in the future. Each of these environments requires its own set of dependencies. Merging several of them into one Debian package leads to the dependency problems which I would like to prevent.. Max
Re: Bug#321955
(Cc to the list, to collect more opinions.. it's about a bugreport for the Debian libapreq2 package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321955 ) On 2005/08/12 23:52, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > On Mon, Aug 08, 2005 at 05:41:26PM +0200, Max Kellermann wrote: > > By the way, the perl modules Apache2::* are only convenience > > libraries providing similar interfaces to CGI.pm and libapreq1. > > The "main" modules are APR::Request etc. Therefore, I do not like > > the package name you chose (libapache2-request-perl). It should > > rather be "libapr-request-perl". > > > > What do you think about: > > > > libapr-request-perl Depends libapreq2 > > libapr-request-apache2-perl Depends libapr-request-perl, > > libapache2-mod-apreq2 > > I'm not sure if I'd like yet another package split -- it's already > up to five binary packages for what I think is a relatively simple > package. Adding libapr-request-perl and libapr-request-apache2-perl > would be two more, totalling seven (one of them a dummy transitional > package)... hm, libapreq2 can be used in many different ways... dependencies are important, but forcing everyone to install all dependencies (Apache2 in this case) is too much for my taste. That's worse than just having another package split, eating up only space for another copy of the same changelog. > I might be skewed here, but are people really going to search for > ???APR::Request::Apache2??? and not ???Apache2::Request??? when > going for the package? I'd probably be happy just splitting out > libapr-request-perl to make it possible to use the module without > Apache, and keep libapache2-request-perl as it is... or would that > be evil? APR::Request is the main Perl package of libapreq2, so pointing that out seems most important to me. Apache2::Request is just a wrapper library for APR::Request::Apache2, but you could argue to keep the old package name (although it isn't 100% correct). Max
Re: [VOTE] libapreq2-2.06-dev-rc4
On 2005/07/19 17:21, Joe Schaefer <[EMAIL PROTECTED]> wrote: > > Please test & vote on rc4 for tomorrow's release of: > > http://people.apache.org/~joes/libapreq2-2.06-dev-rc4.tar.gz tests run fine on Debian/amd64. I did a quick test on FreeBSD, without the perl glue. The build fails with the following message: Making all in module Making all in apache2 make: don't know how to make all-local. Stop *** Error code 1 It turns out that the generated Makefile.in contains: all-am: Makefile $(LTLIBRARIES) $(HEADERS) all-local .PHONY: GTAGS all all-am all-local [...] @[EMAIL PROTECTED]: @APACHE2_HTTPD@ With GNU make, this is no problem: [EMAIL PROTECTED]:~/src/libapreq2-2.06-dev/module/apache2$ gmake all-local gmake: Nothing to be done for `all-local'. [EMAIL PROTECTED]:~/src/libapreq2-2.06-dev/module/apache2$ make all-local make: don't know how to make all-local. Stop GNU make seems to accept the implicit target declaration through ".PHONY", BSD make does not. I believe this is an automake bug, because it incorrectly creates a dependency on "all-local" even when there is no "all-local" because the condition to generate it was not met. I'll try to write a workaround for that later... Max
