Date: Fri, 27 May 2011 20:08:44 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: cvs-ports@FreeBSD.ORG, cvs-all@FreeBSD.ORG, ports-committers@FreeBSD.ORG Subject: Re: cvs commit: ports/sysutils/ganglia-webfrontend Makefile pkg-plist Message-ID: <20110527200844.GA43111@FreeBSD.org> In-Reply-To: <20110527111529.GB24282@lor.one-eyed-alien.net> References: <201105252314.p4PNEeV0010445@repoman.freebsd.org> <20110527025402.GA2175@FreeBSD.org> <20110527111529.GB24282@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110527200844.GA43111>