Bug 259240 - devel/glib20 at version 2.70 pulls in dbus as a mandatory dependency
Summary: devel/glib20 at version 2.70 pulls in dbus as a mandatory dependency
Status: Closed Unable to Reproduce
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-desktop (Team)
URL:
Keywords:
Depends on:
Blocks: 257623
  Show dependency treegraph
 
Reported: 2021-10-18 01:31 UTC by Masuji
Modified: 2021-10-19 04:34 UTC (History)
2 users (show)

See Also:
tcberner: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Masuji 2021-10-18 01:31:47 UTC
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.
Comment 1 Tobias C. Berner freebsd_committer freebsd_triage 2021-10-18 16:49:35 UTC
Moin moin 

DBus is only required by the TEST option, as far as I can see.


mfg Tobias
Comment 2 Masuji 2021-10-18 17:18:53 UTC
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.
Comment 3 Jan Beich freebsd_committer freebsd_triage 2021-10-18 19:01:27 UTC
(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.
Comment 4 Jan Beich freebsd_committer freebsd_triage 2021-10-18 19:14:40 UTC
(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.
Comment 5 Masuji 2021-10-19 01:04:22 UTC
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.
Comment 6 Masuji 2021-10-19 04:34:50 UTC
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.