From owner-freebsd-ports@FreeBSD.ORG Sun Feb 9 13:51:52 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30FA54F1 for ; Sun, 9 Feb 2014 13:51:52 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CFFFE1781 for ; Sun, 9 Feb 2014 13:51:51 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s19Dpnxo003715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Feb 2014 06:51:49 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s19Dpndk003712; Sun, 9 Feb 2014 06:51:49 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 9 Feb 2014 06:51:49 -0700 (MST) From: Warren Block To: Andrea Venturoli Subject: Re: ICU sweeping upgrade: bug or feature? In-Reply-To: <52F78316.2010502@netfence.it> Message-ID: References: <52F6132C.3070406@netfence.it> <52F78316.2010502@netfence.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 09 Feb 2014 06:51:50 -0700 (MST) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 13:51:52 -0000 On Sun, 9 Feb 2014, Andrea Venturoli wrote: > On 02/08/14 18:08, Warren Block wrote: > >> This may very well come back to bite you in the future, > > Well, as I said, this is just a temporary fix for something that, IMVHO, > shouldn't have broken in the first place. Well, yes. >> causing >> mysterious failures long after you've forgotten you did it. > > I periodically clean /usr/local/lib/compat/pkg, so it shouldn't be long > before the links and the libraries they are aliasing are both gone. > > However, what is different here from what portupgrade usually does (i.e. > leaving old libraries in that compat dir)? Sorry, I had missed that. No, it should not be as bad in compat/pkg, particularly as a temporary thing. Soft-linking libraries in the main shlib directories has come up as a frequent "fix" in the forums, along with trying to fix the long-term problems because it is usually considered a fix rather than a temporary workaround. >> Running pkg_libchk [-q] after port upgrades has worked well for me. It >> is from sysutils/bsdadminscripts by Dominic Fandrey, and easily detects >> applications that are using old libraries and should be rebuilt. It >> worked this time also. > > I normally use sysutils/libchk. I never tried pkg_libchk, but I'm curious. > What is the advantage of one over the other? >From memory, the output of pkg_libchk was more useful than that of libchk.