From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28108 invoked by alias); 8 Dec 2003 23:44:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28100 invoked from network); 8 Dec 2003 23:44:14 -0000 Received: from unknown (HELO mailout.TechFak.Uni-Bielefeld.DE) (129.70.136.245) by sources.redhat.com with SMTP; 8 Dec 2003 23:44:14 -0000 Received: from xayide.TechFak.Uni-Bielefeld.DE.TechFak.Uni-Bielefeld.DE (xayide.TechFak.Uni-Bielefeld.DE [129.70.137.35]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id hB8Ni5G13676; Tue, 9 Dec 2003 00:44:05 +0100 (MET) From: Rainer Orth Message-ID: <16341.3267.380410.190238@xayide.TechFak.Uni-Bielefeld.DE> Date: Mon, 08 Dec 2003 23:48:00 -0000 To: Paul Eggert Cc: Alexandre Oliva , Ben Elliston , "Zack Weinberg" , 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} In-Reply-To: <87llpn0wh4.fsf@penguin.cs.ucla.edu> 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> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2003-12/txt/msg00554.txt.bz2 Paul Eggert writes: > That is why my proposal was to switch to -sunos5.10 instead, as that > name is more stable (and has already been decided on within Sun). > > One other advantage of fixing the numbering problem between SunOS 5.9 > and SunOS 5.10 is that configure scripts tend to be buggy in this > area. For example, they might use a pattern like *-solaris2.[0-6]* to > match Solaris 2.0, ..., 2.5, 2.5.1, 2.6, but with the current > config.guess this pattern now unexpectedly matches the output of SunOS > 5.10 (which config.guess currently calls "solaris2.10"). Since SunOS > 5.10 will require maintainers who care about SunOS version numbers to > review their configure scripts for unexpected pattern matches anyway, > having them convert to -sunos5.10 is no big deal. It may even > simplify their patterns a bit. ... and force everyone else (who had their patterns correct or don't require Solaris version-specific handling) to change their configure etc. scripts? For what gain? Why can't you seem to understand the value of backwards compatibility? In all this discussion, the only argument in favor of change has been reduced (newbie) confusion and consistency with vendor nomenclature. I would have thought that my example of the DEC OSF/1 -> Digital UNIX -> Tru64 UNIX name changes together with the vendor change from DEC -> Digital -> Compaq -> HP had made it completely clear that following vendor marketing ideas creates a maintenance nightmare for config.{guess, sub} users, but you don't seem to get that point. Or will your next crusade be to change alpha*-dec-osf* as well? At this point, you cannot even be sure that `Solaris Next' will actually be called `Solaris' at all; maybe they come up with some fancy Java-based name a few days before the release ;-( > (c) Don't make the change at all; just keep the incorrect numbering > indefinitely. > > Obviously (c) is something I'm against fairly strongly, or I wouldn't > have brought up this issue in the first place. I'm quite aware of the > entrenched software that depends on the wrong version numbers, but I > also feel strongly that we should give operating systems proper names > and numbers. This should have been fixed years ago, but better late > than never. (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. Besides, I think this is all moot now since Ben already declared that there will be no change due to the massive impact compared to minimal benefit. Rainer