httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [apreq-2] versioning system
Date Wed, 08 Oct 2003 15:50:22 GMT
Stas Bekman <stas@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


Mime
View raw message