From owner-cvs-all@FreeBSD.ORG Fri May 27 20:08:44 2011 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1033) id 791031065677; Fri, 27 May 2011 20:08:44 +0000 (UTC) Date: Fri, 27 May 2011 20:08:44 +0000 From: Alexey Dokuchaev To: Brooks Davis Message-ID: <20110527200844.GA43111@FreeBSD.org> References: <201105252314.p4PNEeV0010445@repoman.freebsd.org> <20110527025402.GA2175@FreeBSD.org> <20110527111529.GB24282@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20110527111529.GB24282@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.1i Cc: cvs-ports@FreeBSD.ORG, cvs-all@FreeBSD.ORG, ports-committers@FreeBSD.ORG Subject: Re: cvs commit: ports/sysutils/ganglia-webfrontend Makefile pkg-plist 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: Fri, 27 May 2011 20:08:44 -0000 On Fri, May 27, 2011 at 06:15:29AM -0500, Brooks Davis wrote: > On Fri, May 27, 2011 at 02:54:02AM +0000, Alexey Dokuchaev wrote: > > Hmm, I believe "abusing" FOO_DEPENDS is pretty bad practice to follow > > without sufficiently compelling reason. In this case, what prevents you > > properly listing them as BUILD_DEPENDS? For users building from ports > > it would not make a difference, but packages will have sane dependencies, > > no (unless I'm missing something)? > > The package depend tree will be identical because the package always > depends on ganglia-monitor-core which legitimately depends on those > libraries. Since all I care about in this case is that the libraries > exist sufficiently to satisfy configure I'd rather not use the > significantly inferior BUILD_DEPENDS mechanism which requires me to > hardcode LOCALBASE in the search path. I'm afraid I still do not get it. What's so inferior to depend on some file (relative to ${LOCALBASE}) if that's what really required? While I understand that BUILD_DEPENDS lines might look longer than LIB_DEPENDS ones, but that's only because BUILD_DEPENDS are inherently special: while LIB_DEPENDS item is clearly defined shared library with standard usage semantics, BUILD_DEPENDS generally cannot be implemented that concisely, because we do not apriori know exactly which file a port depends on, thus -- fully qualified path. Technically it seems excessive (e.g. while BUILD_DEPENDS is defined, all provided files are installed), but it is useful to keep track of what port needs, and it makes easier to adjust _DEPENDS later as appropriate. This is what I've been trying to enforce for quite a long time: out ports should be stateful. Right now, it is often required to deeply examine the port itself (CVS history) and original vendor's sources to get a clue what's exactly going on, quite often because of incorrect dependencies records! > Now that I think of it, a better solution is probably to just delete > those parts of the configure script when building this package. As I see it, the whole issue (in general case) boils down to this: - If port (not its dependencies!) installs executable that dynamically links to a libfoo.so, add libfoo.so provider port to LIB_DEPENDS - If port loads shared object via dlopen(3) -- add it to RUN_DEPENDS. Adding this library as LIB_DEPENDS won't save you from ABI breakage anyways; either port maintainer (or, better, upstream author) should keep track of these issues to ensure everything is nice and dainty. Last but not least: dlopen(3) is runtime thing, so LIB_DEPENDS is wrong from common sense (we presume that ports framework does not contradict common sense; if it does, we're in a much worse trouble) - If both configure script *and* build require some header file or statically links to an archive (*.a) -- set BUILD_DEPENDS accordingly - If configure script *bogusly* requires something (we all know how crappy this autotools generated stuff can be) -- patch the script ./danfe