From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30296 invoked by alias); 5 Dec 2002 20:11:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30279 invoked from network); 5 Dec 2002 20:11:10 -0000 Received: from unknown (HELO mx07.cluster1.charter.net) (209.225.8.17) by sources.redhat.com with SMTP; 5 Dec 2002 20:11:10 -0000 Received: from [66.189.46.2] (HELO platinum.local.) by mx07.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 5217303; Thu, 05 Dec 2002 15:10:45 -0500 Date: Thu, 05 Dec 2002 12:11:00 -0000 Subject: Re: [RFC] Update to current automake/autoconf/libtool versions. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Daniel Jacobowitz , "Maciej W. Rozycki" , DJ Delorie , ac131313@redhat.com, binutils@sources.redhat.com, gdb-patches@sources.redhat.com To: Doug Evans From: Klee Dienes In-Reply-To: <15855.41422.793808.975309@casey.transmeta.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00167.txt.bz2 As long as the versions of the tools are specified by a version string referencing an official version in README-maintainer-mode, and not by "whatever version is on sourceware.cygnus.com", I'm happy. In practice I can't imagine there would be a problem with versions disappearing from the FSF site before we had upgraded to the current version (the current autoconf repository has versions of autoconf going back to 1996). But if that's a concern, we can always replicate official FSF releases to a local directory and cache them there. On Thursday, December 5, 2002, at 01:58 PM, Doug Evans wrote: > Klee Dienes writes: >> I'd argue that we should: >> >> 1) Specify the versions of autoconf/automake/libtool/gettext by >> reference to official tarballs from ftp.gnu.org. > > This places a requirement on the maintainers of ftp.gnu.org > to not delete said tarballs until binutils has been updated. > I dont' think you or they want that kind of coupling. > Better to uncouple things and have your own tarballs. > Then you can upgrade according to your schedule, not theirs.