Prior to 2.68, and currently according to glib documentation, linux-from-scratch and several other sources, it's an OPTIONAL dependency. There's simply zero reason to require it. This is a regression as it appears to be a new bug to 2.70 Please rectify. Replication steps: cd /usr/ports/devel/glib20 make rmconfig-recursive (to clear out configs) make config-recursive It'll pull dbus in.
Moin moin DBus is only required by the TEST option, as far as I can see. mfg Tobias
Hello Tobias, No dice, even with all options UNSELECTED it is still pulling in dbus. If I use a pre-2.70 version of the ports tree, it does not pull in dbus. I know this because I intentionally hack dbus on the ports tree to be marked as BROKEN, so that if something pulls it in it fails to build. I've checked every other port -- this is absolutely something to do with the glib update.
(In reply to Masuji from comment #0) > This is a regression as it appears to be a new bug to 2.70 Can you reproduce after reverting ports 3014d5a8f0e3? If so your issue is unrelated to 2.70.0 update. (In reply to Masuji from comment #2) > if something pulls it in it fails to build Provide a full build log of that "something". TEST_DEPENDS shouldn't be used outside of "make test" unless Mk/bsd.port.mk has a bug. TEST_DEPENDS is always parsed unlike TEST_BUILD_DEPENDS which honors TEST option.
(In reply to Jan Beich from comment #3) > Can you reproduce after reverting ports 3014d5a8f0e3? "git bisect" is the canonical way to track down regressions. Other approaches (including the quoted one) are more error-prone. For example, it's possible to roll back to 2.68.4 then apply 3014d5a8f0e3 (via git or manually) in order to confirm it's the culprit but there'd be a patch conflict in Makefile due to the adjacent context line (lines outside of context don't matter) being different from when the patch was generated. > If so s/so/not/. Blame the noise on bug 191677.
Hello Jan, So I reverted to the port revision listed, and I reproduced the issue. I am tracing the issue to see if I can rule out glib20 being part of the problem. Something really screwy is going on here, and I suspect that if glib20 isn't part of the issue, it could be something to do with Python, as strange as that sounds. Anyways, I'll close this IF I rule it out.
I uh, after all this was not able to reproduce it on a clean install of FreeBSD, at least for glib20. I apologize for wasting everyone's time here, it may have been a bizarre fluke on my end, or just a cursed/screwed up FreeBSD install. Python 3.9 is pulling it in for some reason through one of its extensions... but I'll have to diag that now. As I began to surmise, this issue is a moving target for me. Thanks guys.