From owner-cvs-all@FreeBSD.ORG Fri Mar 18 08:16:42 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B52216A4FC; Fri, 18 Mar 2005 08:16:41 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A011D43D49; Fri, 18 Mar 2005 08:16:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2I8GDlk036700; Fri, 18 Mar 2005 01:16:13 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423A8DC5.5010006@samsco.org> Date: Fri, 18 Mar 2005 01:13:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Sobolev References: <20050317.233645.74714466.imp@bsdimp.com> <20050318064521.GA42508@VARK.MIT.EDU> <423A86D9.5030504@portaone.com> <20050318.005008.71126625.imp@bsdimp.com> <423A8B51.3010609@portaone.com> In-Reply-To: <423A8B51.3010609@portaone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: danfe@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-src@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG cc: das@FreeBSD.ORG cc: Warner Losh Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 08:16:42 -0000 Maxim Sobolev wrote: > Warner Losh wrote: > >> From: Maxim Sobolev >> Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h >> Date: Fri, 18 Mar 2005 09:44:25 +0200 >> >> >>> David Schultz wrote: >>> >>>> On Thu, Mar 17, 2005, Warner Losh wrote: >>>> >>>> >>>>>> You had better bump the version number for libm before 6.0 rolls >>>>>> around!! I've just found a 3rd party binary-only package that >>>>>> supports 'FreeBSD 5.x' but is linked against libm.so.2. Ugh. We >>>>>> need to bury that mistake and NOT make it again. >>>>> >>>>> >>>>> 6.0 already has /lib/libm.so.3 >>>> >>>> >>>> >>>> So does 5.3. I think Scott's point is that if we're going to bump >>>> it for 6.X at all, we had better do it soon or risk running into >>>> the same mess we had before. I agree with that, although at >>>> present I don't know of a compelling reason to do the bump the >>>> libm version number at all. >>> >>> >>> Haven't several functions been removed from -CURRENT version of libm >>> recently? IMHO this provides sufficient reason for version bump. >>> Actually I think it makes sense to bump all libraries automatically >>> when -CURRENT goes one major number up. There is just no much sense >>> in preserving partial compatibility. >> >> >> >> One of the problems with an overly agressive bumping is that if you >> bump, you have to bump *EVERYTHING* that depends on the library to get >> true compatbility, even the ports (and have different majors build >> based on using libc.so.5 vs libc.so.6, a real pita). When I looked >> into the major abi issues we had a while ago, I came to this >> conclusion. I also came to the conclusion that we'd be better off >> keeping compatibility and *NEVER* bumping a fundamental library's >> major number to avoid these problems. Alas, no one listens to me, and >> they make incompatible changes (like removing functions), so we're >> stuck in the false belief that major numbers are going to save us.[*] > > > What's the problem with ports? I think one who want to run older ports > on newer system can install compatXX package, no? > > -Maxim No, I think that what he's worried about is that you have port foo that generates a library called libfoo.so.1, and that library is linked against libm.so.2. You then have port bar that generates a binary linked against libfoo.so.1 and libm.so.2. Now lets say that libm.so.2 gets bumped to libm.so.3, and you also rebuild port bar. Now bar is linked to libfoo.so.1 and libm.so.3, but libfoo.so.1 is still linked against libm.so.2; mass panic ensues and the universe is driven into chaos and death. Unfortunately, we already tried the tactic of ignoring compatibility, and it bit us in the rear with libm (and a number of other libraries). Many people spent many months sorting that mess out, and I don't really care to repeat that mistake. Warner is right that bumping libraries too often and/or for the wrong reason will also cause problems, so a middle ground has to be found. Keeping eternal backwards compatibility in the source is unmanageble, however. Scott