[Bug 291447] ports-mgmt/synth: www/apache24 "has more dependencies than the port requires"
Date: Mon, 08 Dec 2025 13:03:26 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291447
John Marino <freebsd@marino.st> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |freebsd@marino.st
--- Comment #2 from John Marino <freebsd@marino.st> ---
Summarizing the Makefile file change:
-------
APU_GDBM?= ${LOCALBASE}/lib/apr-util-1/apr_dbm_gdbm.so
. if exists(${APU_GDBM})
LIB_DEPENDS+=libgdbm.so:databases/gdbm
. endif
-------
The problem is that the APU_GDGM variable is evaluated immediately when make
loads the makefile. The variable is checking for the existence of an installed
file. That works fine in case like portmaster (e.g. cd <path-to-port> && make
build).
However, it does not work at all in a "clean environment" where nothing is
installed (such as pouderie or synth).
What's going on is synth is evaluating the makefile in a clean environment
which means databases/gdbm is not added to the list. Obviously synth is able
to build the port so databases/gdbm is listed as a dependency on the actual
package.
The QA check finds the mismatch and deletes it.
Is this a new QA check? because if apr-1 is the one linked with gdbm, then I
would not consider it an error if the package lists apr-1 as a dependency but
not gdbm. This seems like a hack to appease a bad QA check.
There was a choice between making QA happy and breaking the build for all synth
users, where the first option was taken.
is there a solution?
Maybe the apr-1 option values can be used for the conditional dependency add?
Again, what the QA check is doing is debatably wrong. It's saying every port
has to add every linked dependency of its own dependencies, and that sounds
crazy to me. There must be hundreds of ports that could be affected by
dependencies with options to link in other libraries.
If I had the choice to make a bad QA check happy or make synth users happy (of
which there are a lot), I'd choose the users.
How long has this QA check been around? Because if it's new, the person that
wrote it needs to see the fallout
--
You are receiving this mail because:
You are the assignee for the bug.