Re: [Nano-devel] [PATCH 01/10] configure: require autoconf-2.69/automake-1.14

[Mike Frysinger]

On 21 Feb 2017 18:40, Benno Schulenberg wrote:
> On Mon, Feb 20, 2017, at 19:42, Mike Frysinger wrote:
> > The autoconf-2.69 release was made in Apr 2012.
> > The automake-1.14 release was made in Jun 2013.
> > 
> > Update the requirements so we know we can rely on macros/features
> > available in those versions.
> 
> I have objected to this before.

i still disagreed with the basis of your argument.  that said, you last
stated that you wanted a 5 year period.  autoconf-2.69 is basically there,
and automake-1.14 is almost 4 years.  if we tried to adhere to 5 years for
automake, that'd mean we'd have to go back to 1.11, and iirc a lot of the
good stuff started coming in 1.12.  so if we go with 1.12, we might as well
go with 1.14 since those releases were so close to each other.

> But... I build the release tarballs
> on a fully up-to-date system, having automake-1.15, which means that
> if someone takes such a tarball and makes a change that requires the
> rebuilding of the configure script, it then /requires/ the presence
> of automake-1.15, because this requirement is baked into several of
> the m4 scripts.

i'm pretty sure that's incorrect.  configure is an autoconf script, not
automake.  and nothing is stopping people from rebuilding all of the
autotools logic which means they can use any version they want.

> I think this is ridiculous.  If I want to avoid this,
> I would have to purposefully build the release tarballs on an older
> system, so that users with systems that are not older than that can
> fiddle with the tarball without problems.  (Not that there will be
> many users who do that, but /I/ used to that, and with nano it always
> worked -- apparently Chris built his releases on sufficiently old
> systems, or he had a way to avoid this automatic version pegging.)

i think you're trying to use autotools incorrectly.  the point of making
a release tarball is so that people don't have to use/worry about running
autotools.  if they want to actually hack on things, then they can turn
to the SCM (i.e. git).  and requesting they have a recentish system isn't
an unreasonable or uncommon requirement.  it's a fairly common status quo
in the open source world.
-mike

signature.asc
Description: Digital signature