You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2003/10/05 19:01:50 UTC
[apreq-2] versioning system
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/
SHARED LIBRARY:
Now: /usr/local/apache2/lib/libapreq.so.2.0.0
Suggested: /usr/local/apache2/lib/libapreq2.so.0.0.0
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:
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.
Thanks.
--
Joe Schaefer
Re: [apreq-2] versioning system
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>Stas Bekman <st...@stason.org> writes:
>>
>>
>>>Joe Schaefer wrote:
>>
>>[...]
>>
>>
>>>>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/
>>
>>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.
>
>
> Never mind, they do have the version number incorporated in
> apr's default layout (<apr> in config.layout). Because httpd installs
> apr in an application-specific directory (not a system-wide one),
> it's ok to drop the apr version number.
>
> Not sure where this leaves us, since vendors sometimes install libapr
> and httpd in system-wide locations (ie /usr, not in /usr/local/apache2).
> I do not want to maintain a config.layout file for apreq, not even
> if it means tracking apr's config.layout from time to time.
whatever you choose is fine, since apreq2-config will tell where it is. And
vendors will have to adjust apreq2-config if they change the default.
As suggested before use include/libapreq2/ to avoid collisions with future
generations.
__________________________________________________________________
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
Re: [apreq-2] versioning system
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> Stas Bekman <st...@stason.org> writes:
>
> > Joe Schaefer wrote:
>
> [...]
>
> > > 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/
>
> 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.
Never mind, they do have the version number incorporated in
apr's default layout (<apr> in config.layout). Because httpd installs
apr in an application-specific directory (not a system-wide one),
it's ok to drop the apr version number.
Not sure where this leaves us, since vendors sometimes install libapr
and httpd in system-wide locations (ie /usr, not in /usr/local/apache2).
I do not want to maintain a config.layout file for apreq, not even
if it means tracking apr's config.layout from time to time.
--
Joe Schaefer
Re: [apreq-2] versioning system
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
>>>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/
>
>
> 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
code-base.
>>>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 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.
>
>
> ++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
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
Re: [apreq-2] versioning system
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
[...]
> > 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/
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.
[...]
> > 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?
[...]
> 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.
++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?
--
Joe Schaefer
Re: [apreq-2] versioning system
Posted by Stas Bekman <st...@stason.org>.
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
Re: [VOTE] apreq-2 versioning system
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 10 Oct 2003, Stas Bekman wrote:
> Joe Schaefer wrote:
> > Here's what I propose we do regarding versioning for
> > httpd-apreq-2. There are 3 objects we need to
> > track independently: libapreq, mod_apreq, and the perl
> > modules.
> [...]
> > [+1]: joes, stas
> > [0]:
> > [-1]:
+1 for me as well ...
--
best regards,
randy
Re: [VOTE] apreq-2 versioning system
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Here's what I propose we do regarding versioning for
> httpd-apreq-2. There are 3 objects we need to
> track independently: libapreq, mod_apreq, and the perl
> modules.
[...]
> [+1]: joes, stas
> [0]:
> [-1]:
__________________________________________________________________
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
Re: clarification? Re: [VOTE] apreq-2 versioning system
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <st...@stason.org> writes:
>
>
> [...]
>
>
>>>>rename? Do we have already Apache::libapreq?
>>>
>>>We do.
>>
>>You mean, in httpd-apreq (1)? I can't find it in httpd-apreq-2:
>>
>> httpd-apreq-2> find . | grep libapreq.pm
>>
>>gives nothing.
>
>
> Sorry- I meant it already exists in httpd-apreq. There's
> no equivalent in httpd-apreq-2 yet. My comments related
> to Apache::libapreq2 were completely speculative.
Thanks Joe. So the vote should probably be:
2) Add Apache::libapreq2, which should
make the same installation info available that the
apreq2-config script does.
;) but no need to repost it, it's clear now.
__________________________________________________________________
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
Re: [apreq-2] redirect on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 11 Oct 2003, Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> [...]
>
> > -GET_BODY("/apreq_redirect_test?test=ok&location=$location%3Ftest=redirect"),
> > +GET_BODY("/apreq_redirect_test?test=ok&location=$location&test=redirect"),
> ^
> ^
> %3F is "?", not "&". Try the tests again with the shortened 10-byte
> $filler and "?" instead of "&". Do all 4 redirect tests still fail?
Yes, they fail the same way as with %3F - no redirect at all
is attempted (ie, in mod_apreq_redirect_test.c, loc is
null).
--
best regards,
randy
Re: [apreq-2] redirect on Win32
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> -GET_BODY("/apreq_redirect_test?test=ok&location=$location%3Ftest=redirect"),
> +GET_BODY("/apreq_redirect_test?test=ok&location=$location&test=redirect"),
^
^
%3F is "?", not "&". Try the tests again with the shortened 10-byte
$filler and "?" instead of "&". Do all 4 redirect tests still fail?
--
Joe Schaefer
Re: [apreq-2] redirect on Win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 11 Oct 2003, Joe Schaefer wrote:
>
>
>>I now remember seeing this condition when I first wrote the
>>tests. There was a bug in apreq_parse_query_string() that disallowed
>>"=" signs in parameter values. I bet you're linking against
>>an older, installed version of libapreq instead of one built
>>from current cvs (the fix to apreq_params.c was applied when
>>I added the redirect tests last week).
>
>
> You're right (blush :) Thanks very much - the tests are
> all fine now, with the original env/t/request.t.
Both, mod_perl and libapreq users (and developers) quite often suffer from
this problem. Long ago I have suggested to have some magic number check, which
will verify that .so and .pm that are being loaded are from the same build.
Unfortunately I never had a chance to implement it. If apreq does it first,
I'll sure thing "steal" it for mod_perl ;)
__________________________________________________________________
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
Re: [apreq-2] redirect on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 11 Oct 2003, Joe Schaefer wrote:
> I now remember seeing this condition when I first wrote the
> tests. There was a bug in apreq_parse_query_string() that disallowed
> "=" signs in parameter values. I bet you're linking against
> an older, installed version of libapreq instead of one built
> from current cvs (the fix to apreq_params.c was applied when
> I added the redirect tests last week).
You're right (blush :) Thanks very much - the tests are
all fine now, with the original env/t/request.t.
--
best regards,
randy
Re: [apreq-2] redirect on Win32
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> Hi,
> There seems to be a problem with the apreq_redirect_test
> on Win32 with apreq-2. First off, env/t/request.t gives
> the results in the attached t1.txt, with the error log
> being e1.txt. The problem here is that no location is
> extracted (in e1.txt, there's debug messages from
> mod_apreq_redirect_test.c saying "looking for new location",
> but no corresponding "redirecting to / ..." twin.
I now remember seeing this condition when I first wrote the
tests. There was a bug in apreq_parse_query_string() that disallowed
"=" signs in parameter values. I bet you're linking against
an older, installed version of libapreq instead of one built
from current cvs (the fix to apreq_params.c was applied when
I added the redirect tests last week).
--
Joe Schaefer
[apreq-2] redirect on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
Hi,
There seems to be a problem with the apreq_redirect_test
on Win32 with apreq-2. First off, env/t/request.t gives
the results in the attached t1.txt, with the error log
being e1.txt. The problem here is that no location is
extracted (in e1.txt, there's debug messages from
mod_apreq_redirect_test.c saying "looking for new location",
but no corresponding "redirecting to / ..." twin. If I
apply the following to env/t/request.t:
==========================================================
Index: t/request.t
===================================================================
RCS file: /home/cvs/httpd-apreq-2/env/t/request.t,v
retrieving revision 1.6
diff -u -r1.6 request.t
--- t/request.t 1 Oct 2003 20:00:36 -0000 1.6
+++ t/request.t 11 Oct 2003 01:26:57 -0000
@@ -19,7 +19,7 @@
ok t_cmp(403, GET_RC("/apreq_access_test"), "access denied");
-my $filler = "0123456789" x 6400; # < 64K
+my $filler = "0123456789"; # < 64K
my $body = POST_BODY("/apreq_access_test?foo=1;",
content => "bar=2&quux=$filler;test=6&more=$filler");
ok t_cmp(<<EOT, $body, "prefetch credentials");
@@ -36,10 +36,10 @@
foreach my $location ('/apreq_request_test', '/apreq_access_test') {
ok t_cmp("ARGS:\n\ttest => redirect\n",
- GET_BODY("/apreq_redirect_test?test=ok&location=$location%3Ftest=redirect"),
+ GET_BODY("/apreq_redirect_test?test=ok&location=$location&test=redirect"),
"redirect GET");
- $body = POST_BODY("/apreq_redirect_test?location=$location%3Ffoo=bar", content =>
+ $body = POST_BODY("/apreq_redirect_test?location=$location&foo=bar", content =>
"quux=$filler;test=redirect+with+prefetch;more=$filler");
ok t_cmp(<<EOT, $body, "redirect with prefetch");
============================================================================
(I changed the size of $filler for ease of debugging), then
the results of env/t/request.t occur in t2.txt, with the
error log being e2.txt. In this case the redirect does
happen, but it's just to, eg, /apreq_access_test, without
the rest of the args needed for the tests.
This is with Apache/2.0.47. Does the above suggest anything
to try? Thanks.
--
best regards,
randy
Re: clarification? Re: [VOTE] apreq-2 versioning system
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
[...]
> >>rename? Do we have already Apache::libapreq?
> > We do.
>
> You mean, in httpd-apreq (1)? I can't find it in httpd-apreq-2:
>
> httpd-apreq-2> find . | grep libapreq.pm
>
> gives nothing.
Sorry- I meant it already exists in httpd-apreq. There's
no equivalent in httpd-apreq-2 yet. My comments related
to Apache::libapreq2 were completely speculative.
--
Joe Schaefer
Re: clarification? Re: [VOTE] apreq-2 versioning system
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>[...]
>>
>>Before I vote, there are a few issues with the perl glue.
>>
>>
>>>for the perl glue-
>>> 1) Apache::Cookie and Apache::Request will be versioned
>>>starting from 2.0. This will likely cause pain for 1.3
>>> users that set their dependency requirements based on
>>> Apache::Request's version instead of libapreq's.
>>
>>hopefully, this generation won't have its versions mismatching the
>>release versions (in 1.x we had 1, 1.1, 1.2),
>
>
> Which did match the release versions for 1.x, didn't they?
>
>
>>whereas here we probably want to have 2.00, 2.01, ... 2.15 etc.
>
>
> To clarify: in 1.x the version numbers for the perl modules always
> matched the *package* release number. So what you're saying is that we
> should stick to this policy, but be sure to use 2.xx (two-digits for
> the minor number) instead? If so, that's fine with me.
Sorry, I wasn't clear what I was talking about. I meant that versioning in the
Changes file. Currently we have in httpd-apreq/Changes:
=item 1.30 - September 27, 2003
libapreq-1.3 is released.
Here the Changes version doesn't match release version, should have been
libapreq-1.30.
>>Also should Apache::Request's version be the only one that has
>>$VERSION and use that for the release version?
>
>
> Do you see an advantage in that? If we're syncing the perl module
> versions with the package release version, I don't see any benefit
> in maintaining that policy for just Request.pm and not Cookie.pm.
> Remember these modules do not depend on one another in apreq-1, nor in
> apreq-2.
Let's say that the libapreq package version is unrelated to either of the .pm
files.
Normally, a version number is not bumped up on each fix, but only during the
release time. So may be the following will work?
Independently for Request.pm and Cookie.pm, bump up each ones version number
just before doing a realy, if and only if, that file has changed from the
previous release? So if Request.pm was at version 2.01 and it hasn't changed
between apreq releases 2.09 and 2.10, it should have the same version as
before. If Cookie.pm was at version 2.05 and was changed several times since
apreq-2.09, its version should be 2.06 when apreq-2.10 is released. Does this
sound good? Or should the version of .pm files be bumped up on each commit to
that file?
Another approach is not to maintain these package numbers at all, instead
require users to work with Apache::libapreq2 which will maintain a single
version number for all .pm files and match libapreq's distro number. I think
that'd be the simplest solution.
>>> 2) Apache::libapreq will be renamed Apache::libapreq2, and should
>>> make the same installation info available that the
>>>apreq2-config script does.
>>
>>rename? Do we have already Apache::libapreq?
>
>
> We do.
You mean, in httpd-apreq (1)? I can't find it in httpd-apreq-2:
httpd-apreq-2> find . | grep libapreq.pm
gives nothing.
>>What's important is that Apache::libapreq2 is needed only for CPAN module
>>dependecies. It shouldn't contain any code and shouldn't be really
>>used in the modules.
>
>
> Right- just like in the 1.x versions, it should be pure perl module just
> to locate config/install data for building other perl modules that want
> to interface with libapreq somehow (roughly equivalent to apreq2-config
> + some additional config info - i.e. typemaps - for reusing the perl
> glue).
>
>
>>Why? Because ideally a program working with libapreq1 should work the
>>same with libapreq2. Similarly, in mod_perl2 we have Apache2.pm, which
>>you can require in MakeMaker for mp2 and Apache.pm for
>>mp1. Incidentally, since mp1 and mp2 aren't compatible each of these
>>modules contain code, but as suggested ideally for apreq it'd be good
>>not to depend on libapreq.pm or libapreq2.pm in the code itself.
>
>
> Yup, +1. The bulk of the perl API of Apache::Request and Apache::Cookie
> should be source compatible with the 1.x versions. However, the matchup
> isn't perfect, and authors that must demand a compatible API (1.x or
> 2.xx) for their application need to be able to do that. Food for
> thought- there may come a time when someone contributes an apache-1.3
> module for libapreq2, in which case folks can use our 2.X API for both
> mp1 and mp2.
sure
__________________________________________________________________
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
Re: c-modules cookie test?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> Hi,
> In looking at the libapreq_cgi tests, I wanted
> to test the cookie stuff under mod_apreq, and came
> up with a c-module handler to do that - this is
> attached. The test, under env/t/cookie.t, say, is
> the same one as under glue/perl/t/apreq/cookie.t,
> with the location adjusted to /apreq_cookie_test.
> Would this be of interest adding?
> I also have a c-module request test, based on the
> t/apreq/big_input.t test of httpd-apreq-1, which
> GETs and POSTs some large data.
+1 to all.
--
Joe Schaefer
c-modules cookie test?
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
Hi,
In looking at the libapreq_cgi tests, I wanted
to test the cookie stuff under mod_apreq, and came
up with a c-module handler to do that - this is
attached. The test, under env/t/cookie.t, say, is
the same one as under glue/perl/t/apreq/cookie.t,
with the location adjusted to /apreq_cookie_test.
Would this be of interest adding?
I also have a c-module request test, based on the
t/apreq/big_input.t test of httpd-apreq-1, which
GETs and POSTs some large data.
--
best regards,
randy
Re: clarification? Re: [VOTE] apreq-2 versioning system
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> [...]
>
> Before I vote, there are a few issues with the perl glue.
>
> > for the perl glue-
> > 1) Apache::Cookie and Apache::Request will be versioned
> > starting from 2.0. This will likely cause pain for 1.3
> > users that set their dependency requirements based on
> > Apache::Request's version instead of libapreq's.
>
> hopefully, this generation won't have its versions mismatching the
> release versions (in 1.x we had 1, 1.1, 1.2),
Which did match the release versions for 1.x, didn't they?
> whereas here we probably want to have 2.00, 2.01, ... 2.15 etc.
To clarify: in 1.x the version numbers for the perl modules always
matched the *package* release number. So what you're saying is that we
should stick to this policy, but be sure to use 2.xx (two-digits for
the minor number) instead? If so, that's fine with me.
> Also should Apache::Request's version be the only one that has
> $VERSION and use that for the release version?
Do you see an advantage in that? If we're syncing the perl module
versions with the package release version, I don't see any benefit
in maintaining that policy for just Request.pm and not Cookie.pm.
Remember these modules do not depend on one another in apreq-1, nor in
apreq-2.
>
> > 2) Apache::libapreq will be renamed Apache::libapreq2, and should
> > make the same installation info available that the
> > apreq2-config script does.
>
> rename? Do we have already Apache::libapreq?
We do.
> What's important is that Apache::libapreq2 is needed only for CPAN module
> dependecies. It shouldn't contain any code and shouldn't be really
> used in the modules.
Right- just like in the 1.x versions, it should be pure perl module just
to locate config/install data for building other perl modules that want
to interface with libapreq somehow (roughly equivalent to apreq2-config
+ some additional config info - i.e. typemaps - for reusing the perl
glue).
> Why? Because ideally a program working with libapreq1 should work the
> same with libapreq2. Similarly, in mod_perl2 we have Apache2.pm, which
> you can require in MakeMaker for mp2 and Apache.pm for
> mp1. Incidentally, since mp1 and mp2 aren't compatible each of these
> modules contain code, but as suggested ideally for apreq it'd be good
> not to depend on libapreq.pm or libapreq2.pm in the code itself.
Yup, +1. The bulk of the perl API of Apache::Request and Apache::Cookie
should be source compatible with the 1.x versions. However, the matchup
isn't perfect, and authors that must demand a compatible API (1.x or
2.xx) for their application need to be able to do that. Food for
thought- there may come a time when someone contributes an apache-1.3
module for libapreq2, in which case folks can use our 2.X API for both
mp1 and mp2.
--
Joe Schaefer
clarification? Re: [VOTE] apreq-2 versioning system
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
[...]
Before I vote, there are a few issues with the perl glue.
> for the perl glue-
>
> 1) Apache::Cookie and Apache::Request will be versioned
> starting from 2.0. This will likely cause pain for 1.3
> users that set their dependency requirements based on
> Apache::Request's version instead of libapreq's.
hopefully, this generation won't have its versions mismatching the release
versions (in 1.x we had 1, 1.1, 1.2), whereas here we probably want to have
2.00, 2.01, ... 2.15 etc.
Also should Apache::Request's version be the only one that has $VERSION and
use that for the release version?
> 2) Apache::libapreq will be renamed Apache::libapreq2, and should
> make the same installation info available that the
> apreq2-config script does.
rename? Do we have already Apache::libapreq?
What's important is that Apache::libapreq2 is needed only for CPAN module
dependecies. It shouldn't contain any code and shouldn't be really used in the
modules. Why? Because ideally a program working with libapreq1 should work the
same with libapreq2. Similarly, in mod_perl2 we have Apache2.pm, which you can
require in MakeMaker for mp2 and Apache.pm for mp1. Incidentally, since mp1
and mp2 aren't compatible each of these modules contain code, but as suggested
ideally for apreq it'd be good not to depend on libapreq.pm or libapreq2.pm in
the code itself.
__________________________________________________________________
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
Re: [VOTE] apreq-2 versioning system
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Here's what I propose we do regarding versioning for
httpd-apreq-2. There are 3 objects we need to
track independently: libapreq, mod_apreq, and the perl
modules.
Based on the prior discussion, here's what I propose:
for libapreq-
Adopt library versioning based on http://apr.apache.org/versioning.html
1) change the resulting library name from libapreq to libapreq2.
2) add apreq2-config.in based on apu-config.in,
supporting similar options.
3) add src/apreq_version.[ch] based on apr-util's corresponding files.
4) add build/get-version.sh to generate (internally) library
version numbers from src/apreq_version.h.
5) update acinclude.m4, configure.ac, xsbuilder.pl and the
various Makefile.am's to support the new files.
for mod_apreq-
Adopt a MODULE_MAJIC_NUMBER scheme similar to httpd:
1) add an "apreq_env_number" constant to apreq_env.h,
2) make mod_apreq.c's MODULE_MAJIC_NUMBER available through it.
for the perl glue-
1) Apache::Cookie and Apache::Request will be versioned
starting from 2.0. This will likely cause pain for 1.3
users that set their dependency requirements based on
Apache::Request's version instead of libapreq's.
2) Apache::libapreq will be renamed Apache::libapreq2, and should
make the same installation info available that the
apreq2-config script does.
PLEASE VOTE:
[+1]: joes
[0]:
[-1]:
--
Joe Schaefer