From owner-cvs-all@FreeBSD.ORG Thu Dec 23 21:58:30 2010 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E721106566B for ; Thu, 23 Dec 2010 21:58:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7D28FC12 for ; Thu, 23 Dec 2010 21:58:29 +0000 (UTC) Received: (qmail 6994 invoked by uid 399); 23 Dec 2010 21:58:29 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Dec 2010 21:58:29 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D13C603.2070007@FreeBSD.org> Date: Thu, 23 Dec 2010 13:58:27 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alex Dupre References: <201012221916.oBMJGCMY069579@repoman.freebsd.org> <4D139A36.1080208@FreeBSD.org> <4D139DC9.1010704@FreeBSD.org> <4D13A438.70805@FreeBSD.org> <4D13AA9E.70208@FreeBSD.org> <4D13B360.50204@FreeBSD.org> In-Reply-To: <4D13B360.50204@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Messenger , cvs-ports@freebsd.org, cvs-all@freebsd.org, ports-committers@freebsd.org Subject: Re: cvs commit: ports/security/dirmngr Makefile ports/security/gnupg Makefile ports/security/gpa Makefile ports/security/gpgme Makefile ports/security/libassuan Makefile distinfo pkg-descr ports/security/opensc Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 21:58:30 -0000 On 12/23/2010 12:38, Alex Dupre wrote: > Doug Barton ha scritto: >> And what *I* am saying is that if there is a bug elsewhere, it should be >> fixed elsewhere. > > I agree with you, but "elsewhere" is tricky here: libtool is not > libassuan, but the libassuan tarball includes libtool, so you "have" to > use the external libtool to handle this issue correctly. > > USE_AUTOTOOLS= libtool > USE_GNOME= ltverhack I am willing to be educated here, so help me out. What is "this issue," what is libassuan not doing correctly, and what is the different thing that those 2 knobs are going to do that is correct? >> Meanwhile, if anyone else wants to engage in idle >> speculation it's going to be ignored. Discussion based on facts is >> always welcome of course. > > The fact is that libassuan 2.0.1 added a few interfaces, and so bumped > LT_CURRENT and LT_AGE to 1 (before they were 0): > > # LT Version numbers, remember to change them just *before* a release. > # (Code changed: REVISION++) > # (Interfaces added/removed/changed: CURRENT++, REVISION=0) > # (Interfaces added: AGE++) > # (Interfaces removed/changed: AGE=0) > # > LIBASSUAN_LT_CURRENT=1 > LIBASSUAN_LT_AGE=1 > LIBASSUAN_LT_REVISION=0 > > This means that the new library is backward compatible with 2.0.0 and a > shared library bump is not needed, simplifying the port update. It sounds to me like what you're saying here is that you disagree with the vendor's choice to bump the library version, and you would prefer that in my port I override their decision. If I'm understanding you correctly I've already stated, on several occasions, why I think that's a bad idea. In no particular order: 1. We have no idea what future plans the vendor has for this software, or the many other related components that are also managed by the same vendor. 2. We have no idea what plans other 3rd parties who rely on libassuan have, and how they may plan to use the library version as a distinguishing factor. 3. We have no idea how other, as yet unknown and/or unported software might be depending on the version number. 4. Gratuitously changing things from what the vendor specifies is a bad idea in general because it makes it harder for people coming from other platforms to use FreeBSD stuff with their existing projects. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/