From owner-cvs-all@FreeBSD.ORG Mon Feb 20 02:38:15 2012 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1033) id D2482106566C; Mon, 20 Feb 2012 02:38:15 +0000 (UTC) Date: Mon, 20 Feb 2012 02:38:15 +0000 From: Alexey Dokuchaev To: Doug Barton Message-ID: <20120220023815.GA49785@FreeBSD.org> References: <201202182356.q1INuU7V061378@repoman.freebsd.org> <20120219060053.GA45762@FreeBSD.org> <20120219150943.GA6673@magic.hamla.org> <20120219164528.GA48166@FreeBSD.org> <20120219175645.GA6833@magic.hamla.org> <20120219191106.GA71541@FreeBSD.org> <20120219203937.GA6943@magic.hamla.org> <20120220012336.GA41983@FreeBSD.org> <4F41A3E5.6030807@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F41A3E5.6030807@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: cvs-ports@FreeBSD.org, Eitan Adler , cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/devel/adime Makefile ports/x11-wm/icewm Makefile ports/graphics/scr2png Makefile ports/x11/xbindkeys 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: Mon, 20 Feb 2012 02:38:15 -0000 On Sun, Feb 19, 2012 at 05:37:41PM -0800, Doug Barton wrote: > On 02/19/2012 17:23, Alexey Dokuchaev wrote: > > "Wine argument" > > I think you meant "Whine" :) ;-)) > 1. The vast majority of the time dependent ports work with any version > of the library. Therefore over-specifying the version numbers creates > useless churn in the CVS repo, and can cause users to needlessly > recompile things that are already working just fine. By design, shlib bump indicates ABI changes. Version number is recorded within the executable. Users would be able to continue using their things after dependency update with shlib version change only as long as they have old library preserved in /usr/local/lib/compat/pkg. For existing packages, shlib version is always recorded regardless of if it's specified in LIB_DEPENDS or not. > 2. In those cases where we know that a thing needs at least a certain > version of a lib, it should be specified with >=, and then left alone. What if next version will break it? How can we be sure about the "at least" part? > Your argument seems to boil down to, "Since we can't be sure, always > specify, and always bump." Right. When dependent ABI changes, consumers must be recompiled. Exact version in LIB_DEPENDS lines is not strictly required, but helps to keep track. It's orthogonal to PORTREVISION. > My counterargument is that doing what you suggest defeats the whole > purpose of shared libs in the first place. > > Imagine the following scenario: > 1. User installs a system, including various ports, including libfoo.so.1 > 2. User does not upgrade system for $N $time_periods. > 3. libfoo is updated and the current version of the shared lib is > libfoo.so.2 > 3. User wants shiny new port binbar. binbar works just fine with either > version of libfoo, so after updating the ports tree the user now > attempts to install binbar. What should happen? > > IMO if the libfoo dependency is properly specified the user should be > able to make/install binbar without having to upgrade libfoo (barring > security issues of course). OK, I see. That's true, I might want to have newest version of the app, but older (stable) version of the dependency. (In fact, I often do! And it's a bit annoying sometimes that portupgrade(8) does not let me to update a port unless I previously agreed to update its dependencies as well.) That said, the problem is not about recompiling existing installed ports when dependency shlib version bumps. It's about upgrading and building new ports against previous (or any) dependency versions without having to hack on LIB_DEPENDS manually. I must admit I do not see how it can be addressed other than removing explicit shlib version number in this case. > Now, is that technical enough for you? :) Yes, it is, thank you. ./danfe