From owner-cvs-src@FreeBSD.ORG Mon Aug 27 17:10:32 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3074716A421; Mon, 27 Aug 2007 17:10:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C434413C48E; Mon, 27 Aug 2007 17:10:31 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7RHAFDT025447; Mon, 27 Aug 2007 13:10:15 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Mon, 27 Aug 2007 13:10:15 -0400 (EDT) Date: Mon, 27 Aug 2007 13:10:14 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200708271041.23205.jhb@freebsd.org> Message-ID: References: <20070824215515.GF16131@turion.vk2pj.dyndns.org> <200708270850.20904.jhb@freebsd.org> <20070827135625.GF29854@garage.freebsd.pl> <200708271041.23205.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, Warner Losh , yar@comp.chem.msu.su Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 17:10:32 -0000 On Mon, 27 Aug 2007, John Baldwin wrote: > > Perhaps a more useful discussion would be how can we use symbol versioning > sanely to support this in the future? The fbsd.hack idea could work, but > it doesn't work in this case because the existing binaries are already > linked. One suggestion that could start with 8.0 could be this: > > - when bumping the version for a symbol in HEAD, instead of going from > fbsd-X.Y to fbsd-X+1.0, put the new symbol as fbsd-current-X+1.0. You > can keep bumping the symbol as fbsd-current-X+1.whatever for subsequent > changes > - when it's time to branch HEAD to RELENG_X+1, you then add fbsd-X+1.0 > symbol versions for the current versions of all the bumped symbols, and > remove all the fbsd-current-* versions and compat shims before the > release (before the RELENG_X+1_0 branch in fact). The rule there being > that no release should ever ship with visible fbsd-current-* symbol > versions. I don't think you need intermediate symbol versions, one should be sufficient. The problem would only arise if you make an ABI change to a function or set of functions that have already had an ABI change in the current version. For example, if there were a function ftsfwrite(FTS, FILE *, ...), and you make the version bump from FBSD_1.0 to FBSD_1.1 when FTS changes, then if FILE changes, you need to bump FBSD_1.1 to FBSD_1.2. If there are no overlapping changes in the ABI, you can continue to add newly changed symbols to the current version (in this case FBSD_1.1). How may times have we ever had overlapping ABI changes in the past? Have we ever? It's not worth fiddling with intermediate symbols, because with that method you're still forcing -current users to rebuild everything just before or after RELEASE to get the final symbols (when the intermediates are removed). If there are no overlapping ABI changes, then no one has to rebuild any ports. -- DE