httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject [apreq-2] versioning system
Date Sun, 05 Oct 2003 17:01:50 GMT
Please take a look at

This raises a few seggestions about how we should
introduce httpd-apreq-2 into the wild.  Given that
libapreq is already out there, the section on 
parallel installations deserves serious consideration.  
In a nutshell, the document suggests we append the API
number "2" to the library name, and ensure that the header 
files are installed in a corresponding version-specific

For instance, here are a few installation changes 
that could result from following the apr guidelines:

  Now:          /usr/local/apache2/include   
  Suggested:    /usr/local/apache2/include/libapreq2/

  Now:          /usr/local/apache2/lib/
  Suggested:    /usr/local/apache2/lib/

Linking to the new libapreq library on a *nix box would
therefore require "-lapreq2" instead of "-lapreq".  To
locate the libapreq2 headers, module authors would then 
need something like

  -I`apxs -q INCLUDEDIR`/libapreq2

The merits of this approach are discussed at:

As far as CPAN is concerned, the new release package would 
then be libapreq2-X.Y.tar.gz, which would not clash with the
old one.  If we decide to to this, I think it would be a good
idea to start telling people on the modperl list to fetch the 
appropriate libapreq package by name 
  % perl -MCPAN -e "get libapreq"
  % perl -MCPAN -e "get libapreq2"

instead of fetching the latest version Apache::Request or 
Apache::Cookie (which will probably get libapreq2, even if
they're really using apache-1.3/modperl-1.3).

Any thoughts on this?  I'd like to bring this issue
to a vote before we do any releases of httpd-apreq-2,
so please express your thoughts.

Joe Schaefer

View raw message