httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [apreq-2] versioning system
Date Mon, 06 Oct 2003 19:50:10 GMT
Joe Schaefer wrote:
> Please take a look at
> 
>   http://apr.apache.org/versioning.html
> 
> 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
> directory. 
> 
> For instance, here are a few installation changes 
> that could result from following the apr guidelines:
> 
> HEADERS:
>   Now:          /usr/local/apache2/include   
>   Suggested:    /usr/local/apache2/include/libapreq2/

That doesn't seem to be the case with apr, as it puts the include files in 
include/

> SHARED LIBRARY:
>   Now:          /usr/local/apache2/lib/libapreq.so.2.0.0
>   Suggested:    /usr/local/apache2/lib/libapreq2.so.0.0.0

I believe that should be libapreq-2.so.0.0.0

at least that's how apr does.

> 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

in that case apreq must provide apreq-config, in parallel to apr-config which 
tell users all the arguments it needs to know. And in no way, you want doing 
the above, since distros will mess around with install dirs and the only way 
to have a single way to configure things is via apreq-config (which distros 
will have to adjust to point to the non-standard dirs).

> The merits of this approach are discussed at:
> 
>   http://www106.pair.com/rhp/parallel.html
> 
> 
> 
> 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"
> or
>   % 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.

CPAN doesn't support versioning. I'm pushing on fixing that and in a few weeks 
there is going to be a CPAN maintainers meeting where this issue should be 
discussed and hopefully fixed.

Meanwhile expect lots of headaches from this issue. This is because even the 
libapreq2 docs will suggest to do the above, CPAN's requirement system will 
still fetch wrong versions, when it sees 'Apache::Request' in requirements. 
The possible workaround is to release a new version of libapreq1 with 
libapreq.pm (or libapreq1.pm) in it (probably moving the version setting to 
it, or syncing it) and adding libapreq2.pm (again the version should be in 
that file (in addition to Apache::Request?). That way modules can now put 
libapreq1 or libareq2 as a prerequisite in their Makefile.PL.

I really hope this CPAN issue will be resolved before mp2 is released.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message