apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [VOTE] Release apr-util 1.4.0
Date Wed, 07 Dec 2011 18:17:08 GMT
On Wed, Dec 7, 2011 at 12:56 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 07 Dec 2011, at 7:32 PM, Jeff Trawick wrote:
>
>> Using the same autoconf and libtool as before should cost you less
>> than 10 minutes, it makes it trivial to review more of the proposed
>> tarball, and it essentially guarantees no regressions in certain
>> aspects of the release.
>>
>> What could be better than that?
>
> Using the same autoconf and libtool as a well supported vendor takes zero minutes, takes
advantage of bug and security fixes provided by that vendor, and completely eliminates the
risk that some manual thing I did messes up the release.

You are the one introducing variations into the release process.  That
is what is introducing risk into the release process.

You are throwing away fixes in later autotools that we have been
shipping with for a number of apr and apr-util releases.

As far as how to install, it is nothing more than the obvious
mechanism, which looks something like this:

wget autoconf
cd autoconf
./configure --prefix=$HOME/autotools_for_apr_releases && make && make install
cd ..
wget libtool
cd libtool
./configure --prefix=$HOME/autotools_for_apr_releases && make && make install
cd ..

Then add the new autotools_for_apr_releases bin director to PATH first
so that it gets used instead of the system libtool/autoconf.

> People build APR using their vendor supplied compilers and tools which will change as
issues are found and fixed. Freezing the versions of autoconf and libtool to an arbitrary
version makes no sense to me.

The "People build APR" part is irrelevant.  The versions of autoconf
and libtool used so far are anything but arbitrary.  They are known to
work for APR users on a variety of platforms.  You're throwing away
fixes we have been shipping with for some time, and AFAICT it is not
practical to evaluate what the real impact is.  (Some AIX level no
longer recognized?  Some new fooBSD not handled properly?  Who knows?)

Perhaps the potential concern with apr-util is much less than with apr
(is it just expat that has nitty gritty considerations?), but I still
think it is generally wrong to deviate without cause, definitely wrong
to backlevel, and aggravating to release testers that the
uninteresting changes to configure-generated files make them hard to
compare with previous releases.

Mime
View raw message