Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Feb 2006 11:37:57 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Sean McNeil <sean@mcneil.com>
Cc:        Daniel Eischen <deischen@freebsd.org>, Doug Barton <dougb@FreeBSD.org>, current@freebsd.org
Subject:   Re: MFC of bump in libcom_err.so another mistake?
Message-ID:  <20060201113447.C57400@fledge.watson.org>
In-Reply-To: <1138786880.99058.3.camel@triton.mcneil.com>
References:  <Pine.GSO.4.43.0601312122360.4643-100000@sea.ntplx.net>  <ED92AAA4-F610-4DC1-A8C5-FDF646D083AF@mcneil.com> <43E05ED9.9000900@FreeBSD.org> <1138786880.99058.3.camel@triton.mcneil.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060201113447.C57400>