From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10541 invoked by alias); 12 Dec 2003 05:38:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10521 invoked from network); 12 Dec 2003 05:38:19 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.73.237.138) by sources.redhat.com with SMTP; 12 Dec 2003 05:38:19 -0000 Received: (qmail 10955 invoked from network); 12 Dec 2003 05:32:05 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 12 Dec 2003 05:32:05 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Thu, 11 Dec 2003 21:38:12 -0800 From: "Zack Weinberg" To: Alexandre Oliva Cc: Rainer Orth , Paul Eggert , Ben Elliston , rms@gnu.org, gcc@gcc.gnu.org, binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: flag day for Solaris portions of config.{guess,sub} References: <8765hf4c8z.fsf@wasabisystems.com> <87wu9mt79r.fsf@egil.codesourcery.com> <871xrs5b9j.fsf@penguin.cs.ucla.edu> <87znegqb31.fsf@codesourcery.com> <87brqsw9d9.fsf@penguin.cs.ucla.edu> <871xroqlaf.fsf@egil.codesourcery.com> <87n0aaj4cl.fsf@penguin.cs.ucla.edu> <87wu9esxu6.fsf@egil.codesourcery.com> <87ad69rf42.fsf@egil.codesourcery.com> <87y8tsx58e.fsf@codesourcery.com> <8765gwvowl.fsf@wasabisystems.com> <87r7zkb6xm.fsf@penguin.cs.ucla.edu> <87llpn0wh4.fsf@penguin.cs.ucla.edu> <16341.3267.380410.190238@xayide.TechFak.Uni-Bielefeld.DE> Date: Fri, 12 Dec 2003 05:38:00 -0000 In-Reply-To: (Alexandre Oliva's message of "12 Dec 2003 03:24:06 -0200") Message-ID: <8765gmzjcr.fsf@egil.codesourcery.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-12/txt/msg00180.txt.bz2 Alexandre Oliva writes: > On Dec 8, 2003, Rainer Orth wrote: > >> (c) is clearly the only option, especially since the only gain of change is >> consistence with (inherently inconsistent and changing) vendor marketing >> whims. You could have made this change in the Solaris 2.0 days, but not >> after the current scheme has been in use for 10 years. > > There's another reason to change from solaris2.10 to something else: > to avoid matches on say solaris2.[0-6]* from matching 2.10. > Backward-compatibility is not an argument to make it solaris2.10: it > *will* expose brokenness. We could do better by using solaris10, > since those that use solaris* will still match, and those that use > 2.[0-6]* won't inappropriately match. *sigh* Must we continue this? configure scripts (and things which are not configure scripts) already exist which _correctly_ match, say, solaris2.[789] | solaris2.1[0-9] . Not exposing bugs in other scripts that have solaris2.[0-6]* is not a reason to break correct scripts. zw