httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [apreq-2] versioning system
Date Wed, 08 Oct 2003 18:28:28 GMT
Joe Schaefer wrote:

>>>For instance, here are a few installation changes that could
>>>result from following the apr guidelines:
>>>  Now:          /usr/local/apache2/include     Suggested:
>>That doesn't seem to be the case with apr, as it puts the include
>>files in include/
> Hmm, that sort of goes against their own recipe for
> parallel installs.  Maybe you or I should ask dev@apr
> and see if this was intentional, or just an oversight.

recently apr-dev seems to have the sound-proof wall installed similar to the 
one built around httpd-dev, so I sort of gave up on trying posting there. They 
do give away commit access if you are willing to fix things, though.

One thing about the docs, is that many times they aren't kept in sync with the 

>>>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). 
> +1 to an apreq-config then.  I'll add a note to STATUS.
> However, shouldn't it be called apreq-2-config or somesuch,
> to plan for parallel installation of a future version 3 of apreq?

Good thinking, Joe. Though I'd suggest to be consistent and have apreq2-config 
(dropping the leading -). Notice that we can play nice and install things into 
includedir/libapreq2/ if apreq2-config reports this dir to be the one.

>>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 (or
>>in it (probably moving the version setting to it, or syncing  it) and
>>adding (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.
> ++Stas!  I'm still shooting for a dev release in a week or so, which
> won't be enough time for this CPAN issue to be resolved.  If we use a
> "_dev" suffix on the package name (like mp2), that should be safe to put 
> on CPAN, right?

Yes, it won't be indexed if the version part includes _ in it (not necessarily 
_dev), e.g. 2.00_01. Also you may want to adopt mp2's idea and have it 1.99_01 
which will become 2.00 once finished.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message