From owner-cvs-src@FreeBSD.ORG Sat Aug 25 03:08:13 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 C021316A418; Sat, 25 Aug 2007 03:08:13 +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 7972B13C442; Sat, 25 Aug 2007 03:08:13 +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 l7P381d3029227; Fri, 24 Aug 2007 23:08:01 -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]); Fri, 24 Aug 2007 23:08:01 -0400 (EDT) Date: Fri, 24 Aug 2007 23:08:01 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Warner Losh In-Reply-To: <20070824.172212.74696955.imp@bsdimp.com> Message-ID: References: <20070824215515.GF16131@turion.vk2pj.dyndns.org> <20070824220244.GH87451@elvis.mu.org> <20070824.172212.74696955.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, 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: Sat, 25 Aug 2007 03:08:14 -0000 On Fri, 24 Aug 2007, Warner Losh wrote: > From: Daniel Eischen > Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h > Date: Fri, 24 Aug 2007 18:25:17 -0400 (EDT) > > The other problem, once you get past the build tools, is now all your > ports binaries do not work. While people running current are big boys > and girls, it is a pain to have to frequently rebuild them. I guess the build system should be more tolerant of this, but there are bound to be problems regardless. I don't see why the install tools can't also either have their own set of libraries (utilizing LD_LIBRARY_PATH) or be built static. >> I never added symbol versioning to libc in order to solve >> -current upgrade problems. Sure, you're free to use it that >> way, but it would not make me very happy ;-) > > So who cares if we find new uses for tools? I never thought devd > would be used for network state transition... > > What's the overhead of having the transition crutch around for a > while? The benefit is that people are less likely to screw up their > systems at a time when we want to encourage people to upgrade so they > can test the latest/greatest version. If it were 9 months after > RELENG_6 was branched, and a long time to a release, then I'd be much > more inclined to agree with the 'current is hard, so why spend > engineering effort on making it easy' crowd than I would now that more > of the world is watching and using it since we're in the glide path to > beta1. > > I don't see why we can't put the versioned symbols in, let everybody > upgrade and then remove the old symbols after a big enough window has > passed. It isn't like they are hurting anything by being there, is > it? If you are going to remove the interim versioned symbols, that's OK with me, but what are you going to do for the people that miss the transistion period (after the interim symbols are removed)? Shouldn't the build system work regardless? If I understand correctly, I think the more general problem is that the install tools are dependent on working with new libraries. > If there is some actual harm here, it hasn't been clearly articulated > and needs to be if that's the case. I'm certainly open to this > possibility. It should be easy to say FBSD_1.0 is RELEASE_7.0, FBBSD_1.1 is RELEASE_7.1, etc. The versioned symbol namespace is mostly to aid the release engineers. If you start to have FBSD_1.2, FBSD_1.3, and FBSD_1.4 are interim versions and FBSD_1.5 is release 7.1, that isn't good. Again, I highly doubt you would have Sun or even Linux have interim versions that are made public. If you want to have interim versions and then remove them at a later point before a release, that is a different story, but it doesn't solve the problem for someone missing the transition period, whereas a more general solution would. -- DE