From owner-cvs-all@FreeBSD.ORG Tue Aug 23 02:42:24 2011 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1033) id E510A1065670; Tue, 23 Aug 2011 02:42:24 +0000 (UTC) Date: Tue, 23 Aug 2011 02:42:24 +0000 From: Alexey Dokuchaev To: Doug Barton Message-ID: <20110823024224.GA99925@FreeBSD.org> References: <201108221821.p7MILBln038468@repoman.freebsd.org> <20110823020838.GA96726@FreeBSD.org> <4E530E26.2090603@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4E530E26.2090603@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: cvs-ports@FreeBSD.org, ports-committers@FreeBSD.org, cvs-all@FreeBSD.org, Pawel Pekala Subject: Re: cvs commit: ports/polish/kadu Makefile distinfo pkg-descr pkg-plist ports/polish/kadu/files patch-kadu-core__CMakeLists.txt patch-kadu-core_gadu_resolver.cpp patch-modules__docking__CMakeLists.txt patch-modules__idle__CMakeLists.txt patch-modules__kde_notify__CMakeLists.txt patch-modules__screenshot__CMakeLists.txt patch-modules__sound__CMakeLists.txt ... 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: Tue, 23 Aug 2011 02:42:25 -0000 On Mon, Aug 22, 2011 at 07:19:18PM -0700, Doug Barton wrote: > > bumping port revision of library consumer ports to chase shlib version > > bumps. > > The version should only be specified for dependents that are tied to a > specific version. If the dependent can survive a version bump of the lib > then the dependency should be specified without version, and NOT bumped > when the lib is updated. I believe it will take too much work to verify which parts of the API port uses and either add or remove this suffix on every update. It's safer to have it; shlib bumps does not happen too often to worry about extra bump. Among useless bumps of port revision (which I am also quite against of), shlib-related ones is a tiny fraction. We should uphold upstream decision (assuming they are not complete idiots to bump shlib version with no good reason) and if they say that API had changed, we had to ensure we chase it. Manual checking is always error prone and can be quite complicated in this particular case. Manual check, however, is the only way to ensure that ports that use library via dlopen(3) remain working. ./danfe