Re: [PATCH] update automake version to 1.11.6

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]

On 20 Mar 2015 16:58, Doug Evans wrote:
> On Thu, Mar 19, 2015 at 4:04 PM, Mike Frysinger wrote:
> > On 19 Mar 2015 15:59, Doug Evans wrote:
> >> On Thu, Mar 19, 2015 at 5:06 AM, Joel Brobecker wrote:
> >> >> Debian stable (wheezy) and newer only have 1.11.6.
> >> >> Ubuntu Trusty and newer only have 1.11.6.
> >> >> Gentoo dropped <=1.11.5 2 years ago.
> >> >> Fedora R17 was the last one to offer 1.11.x (it was 1.11.6).
> >> >> Centos 7 doesn't offer any 1.11.x version.
> >> >> OpenSUSE 12.2 was the last one to offer 1.11.x.
> >> >> Arch Linux dropped 1.11.x 3 years ago.
> >> >> Mageia 2 was the last one to offer 1.11.x.
> >> >>
> >> >> So anyone who readily has access to automake 1.11.[0-5] is using a two
> >> >> year old distro that is no longer supported.  Lets use 1.11.6 as it's
> >> >> the only 1.11.x version that is easily available.
> >> >>
> >> >> 2015-03-14  Mike Frysinger  <vapier@gentoo.org>
> >> >>
> >> >>       * README-maintainer-mode: Update automake to 1.11.6.
> >> >
> >> > FWIW, I tend to avoid using the auto-tools already installed, because
> >> > I don't know what patches they might contain. Those patches can result
> >> > in small differences which inexplicably show up when you regenerate
> >> > some files after making some modifications. That's why I rebuilt
> >> > them all from source, and use them when regenerating files.
> >> >
> >> > All in all, I'm not against switching to 1.11.6 but we should then
> >> > regenerate all affected files now, and I would prefer it if that was
> >> > done using an unmodified release rather than one that might have been
> >> > modified by the distro.
> >>
> >> +1 on avoiding distro releases.
> >
> > if we follow this logic, why aren't autotools part of the repo, either directly
> > (like readline) or indirectly (git submodules) ?  requiring every developer to
> > independently correctly download&build&install a custom version of autotools in
> > their system is, frankly, unreasonable.
> >
> > in Gentoo i've made it dirt simple for people -- older versions of autoconf are
> > available to emerge in parallel and you can select via `autoconf-2.64` or by
> > exporting WANT_AUTOCONF=2.64.  but i don't think making Gentoo a requirement
> > would be approved :D.
> 
> IIRC, There used to be copies of at least one of autoconf/automake on
> sourceware because there were local patches we needed.  They were
> eventually deleted because there was no longer a need for them, and
> when we upgrade to a new version it's easier to just get the release
> from ftp.gnu.org (or wherever).
> 
> It's happened before that distro releases of autoconf/automake
> contained local mods that generated noisy diffs. A distro
> autoconf-2.64 is not necessarily a real autoconf-2.64 (no local mods).

i'm aware of what distros can do -- i'm the maintainer of these packages in 
Gentoo, and i have included upstream fixes before.  and i've seen older versions 
include patches that were ... questionable.

> Requiring everyone to use the same version in order to avoid noisy
> changes is desirable, and requiring people to download/install pure
> FSF copies doesn't really seem that onerous.

i don't have a problem with requiring people to use the same exact version.
i do think that requiring them to build/install by hand is unreasonable.
it's pretty rare (by design) for projects to do this sort of thing (commit
the generated autotools), so it's pretty rare for this to be an issue, so
it's pretty rare for people to be required to manage this.  it's a throw
back to pre-distro days when people were used to building/install software
themselves, and it's unnecessary friction for new people to get into the 
development process today.  death by a thousand cuts and all that.

while i would like to see the autotools not be checked in in the first place, 
i'm not advocating for that here.  if we're going to make this a barrier for
entry, then why don't we make it a non-issue ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]