cvs commit: ports/sysutils/ganglia-webfrontend Makefile
pkg-plist
Alexey Dokuchaev
danfe at FreeBSD.org
Fri May 27 20:08:44 UTC 2011
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
More information about the cvs-all
mailing list