Date: Fri, 24 Aug 2007 18:03:35 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <Pine.GSO.4.64.0708241758120.13181@sea.ntplx.net> In-Reply-To: <20070824214429.GB99474@comp.chem.msu.su> References: <200708230509.l7N59VCi048341@repoman.freebsd.org> <Pine.GSO.4.64.0708241057010.12450@sea.ntplx.net> <20070824183630.GA99474@comp.chem.msu.su> <Pine.GSO.4.64.0708241511440.13181@sea.ntplx.net> <20070824214429.GB99474@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Aug 2007, Yar Tikhiy wrote: > On Fri, Aug 24, 2007 at 03:14:53PM -0400, Daniel Eischen wrote: > >> this way: if there wasn't symbol versioning and libc was >> already bumped, how would you solve the problem? You >> wouldn't bump libc again, right? > > I've believed that symbol versioning should help us to fix bugs, not > prevent us from doing so. Not having to bump the libc version each > time was the main reason to have symbol versioning, wasn't it? The version defs and symbol versioning are for releases, and not meant for use to solve -current upgrade problems. You wouldn't see Sun bump their public version definitions to work around interim ABI changes in their development tree. We will always have issues like this for those running and developing in -current, and we shouldn't be using public version definitions to work around our own internal build problems. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708241758120.13181>