Re: Patches to README-release

[Jim Meyering]

Gary V. Vaughan wrote:

> Hi Jim,
>
> On 28 Jan 2012, at 15:27, Jim Meyering wrote:
>> Gary V. Vaughan wrote:
>>> Hi Jim,
>>>
>>> On 28 ม.ค. 2012, at 1:21, Jim Meyering <address@hidden> wrote:
>>>
>>>    Reuben Thomas wrote:
>>>
>>>        Ping? The patches still apply cleanly to HEAD.
>>>
>>>        On 22 December 2011 19:54, Reuben Thomas <address@hidden> wrote:
>>>
>>>            -* Ensure that the desired versions of autoconf, automake, etc.
>>>            -  are in your PATH.  See the buildreq list in bootstrap.conf for
>>>            -  the complete list.
>>>
>>>    That paragraph is trying to say that one should be careful not to
>>>    prepare a release using anything less than the latest stable releases.
>>>    That is *not* checked by running bootstrap, and hence why I mentioned
>>>    it here.  For example, if I have a working directory with lib/getdate.c
>>>    generated from before the preceding bison release, I should be careful
>>>    to remove it (make maintainer-clean) and regenerate it with the newer
>>>    version of bison.  In this case, "make distclean" is insufficient.
>>>
>>>    I.e., you're welcome to reword it, but not to remove it altogether.
>>>
>>> How about:
>>>
>>> If you have not yet upgraded to saner bootstrap, which check autotools
>>> versions automatically for you, then you'll need to make a painstaking
>>> manual check of the autotools versions in your PATH every time you
>>> want to make a new distribution tarball.
>>
>> You have missed the point.
>> When I make a release, I want to use at least the latest stable
>> build tools.  AC_PREREQ does not necessarily encode that requirement.
>
> Well, that *was* my point.

That was your point?  Really?  You didn't say anything about the
difference between AC_PREREQ and stable/desirable versions of tools.

> I'm wondering what purpose AC_PREREQ (etc) really
> serves if you're not using them to encode the versions of the autotools that 
> are
> required to bootstrap a package in the way expected by the maintainers.

It permits one to build the package unmodified on systems for which
the latest version of autoconf will never be available.
This is a big for e.g., libvirt.

> In other words, does it really make sense to keep track of the minimum version
> capable of bootstrapping one's project, when you really want people to 
> bootstrap

"bootstrap to use on one particular (and well-behaved) system"
is not the same as "bootstrap to release", nominally to be built
on any system in existence.