From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 11:36:03 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4969B16A420; Wed, 1 Feb 2006 11:36:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFEAA43D45; Wed, 1 Feb 2006 11:36:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1A20646B10; Wed, 1 Feb 2006 06:35:54 -0500 (EST) Date: Wed, 1 Feb 2006 11:37:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sean McNeil In-Reply-To: <1138786880.99058.3.camel@triton.mcneil.com> Message-ID: <20060201113447.C57400@fledge.watson.org> References: <43E05ED9.9000900@FreeBSD.org> <1138786880.99058.3.camel@triton.mcneil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , Doug Barton , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 11:36:03 -0000 On Wed, 1 Feb 2006, Sean McNeil wrote: >> I don't know where you got libcom_err.so.2.1, but I don't think it's from a >> FreeBSD system. > > This turned out to be an errant port that was installing > /usr/local/lib/libcom_err.so.2.1 and I guess was later fixed. Seems like it > might have been the fault of cracklib. Sorry for the confusion and noise. > > When I saw libcom_err was part of the base system I made a false assumption > that a revision bump caused the problem. I should have investigated it > further before opening my mouth (email program). Mmmm. Sounds like rather errant behavior for a port, but likely due to Kerberos, which requires rather devious methods to integrate with the base system. It would be interesting to know which binaries depend on the old library -- if you portupgrade'd something that previously provided the old libcom_err, and perhaps not something that depended on it, you may have ended up with a stale binary. If run recursively, portupgrade is generally pretty good about that, so the variant scenario is that you installed something that replaced base system binaries that existed in an old release of FreeBSD, but not a new one, so portupgrade didn't want to delete them. I.e., k5init, which is now just kinit. In the old world order, a port installing k5init would have been overwriting the base system k5init, but in the new world order, there is no base system k5init. Robert N M Watson