Re: Bug#321955
On Sat, 13 Aug 2005 00:54:41 +0200, Max Kellermann wrote: > 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.. Cheers from here :-) I was just going to post a bug report an then discovered this thread. I just wrote a Apache2 module for our servers an (foolishly?) used libapreq2 to handle parameter parsing (mod_apreq2 to be more precise). I was, erm, astonished about the dependencies when i tried to compile the Debian sources Cheers Ralf Mattes > Max
Re: Bug#321955
[Please Cc [EMAIL PROTECTED] if there's something you feel should also go into the bug log] On Sat, Aug 13, 2005 at 12:28:18AM +0200, Max Kellermann wrote: > 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. 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. /* Steinar */ -- Homepage: http://www.sesse.net/
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
