Date: Wed, 1 Feb 2006 01:53:06 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Sean McNeil <sean@mcneil.com> Cc: current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? Message-ID: <20060201014800.E95776@fledge.watson.org> In-Reply-To: <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com> References: <1138476952.86610.1.camel@triton.mcneil.com> <20060131235035.B95776@fledge.watson.org> <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 Jan 2006, Sean McNeil wrote: > On Jan 31, 2006, at 3:52 PM, Robert Watson wrote: > >> On Sat, 28 Jan 2006, Sean McNeil wrote: >> >>> I was wondering if this was on purpose. Seems like there is no good >>> reason that it was done on -STABLE and it has really messed up everything >>> here for me. >>> >>> libcom_err.so.2 bumped to libcom_err.so.3. >> >> It was on purpose, but not necessarily for a good reason. Could you be >> more specific about "really messed up everything here for me", which sounds >> a lot to me like "and all hell broken loose"? I assume there's some sort >> of library and application versioning problem, but some details would be >> helpful. > > I had several big packages that depended on kerberos and they all broke > because: > > 1) libcom_err.so.2.1 was moved to /usr/local/lib/compat/pkg/ > 2) The symlink libcom_err.so.2 was removed and nothing was placed in compat. > > I finally got smart and just added an entry to libmap.conf and so I'm not > "really messed up...". That was not accurate in the first place :) So the real problem was that libcom_err.so.2 was not placed in compat when the version number was bumped. >> In principle, other than potentially requiring compat libs to run old >> binaries even though that may not strictly have been necessary, it seems >> likely that a binary depending on the old libcom_err depends also on an old >> libc. On the other hand, I consider library version number interactions to >> be mysterious, and likely have missed the point. :-) > > The point I am making is that this is in the -STABLE tree, not the -CURRENT > tree. There is no bump of libc and I don't see any reason for the > libcom_err.so revision bump in -STABLE. IMHO, it didn't make sense. There was a bump in libc, it just happened much earlier. The remainder of the libraries were bumped shortly before 6.0-RELEASE, but not after the release once it became -STABLE. Libraries also have ABI dependencies on other library revisions -- i.e., if an API changes in libc, and libypclnt depends on the old version of the API, it needs to use the old libc. Could you grab a libcom_err.so.2 from RELENG_5 and stick it in your compat tree and see what happens? Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060201014800.E95776>