Bug 214992

Summary: devel/dbus: make dependency loop
Product: Ports & Packages Reporter: Keizo Shimizu <keizo>
Component: Individual Port(s)Assignee: Baptiste Daroussin <bapt>
Status: Closed FIXED    
Severity: Affects Many People CC: lantw44, w.schwarzenfeld
Priority: --- Flags: bugzilla: maintainer-feedback? (gnome)
Version: Latest   
Hardware: Any   
OS: Any   

Description Keizo Shimizu 2016-12-02 06:06:56 UTC 
When installing some ports on 11.0-RELEASE-p1, I met 
"Cannot fork: Resource temporarily unavailable" message.
I investigated log and found following make dependency loop.

===>   dbus-glib-0.104 depends on shared library: libdbus-1.so - not found
===>   dbus-1.8.20 depends on executable: xmlto - not found
===>   xmlto-0.0.28 depends on executable: w3m - not found
===>   w3m-0.5.3_5 depends on shared library: libgtk-x11-2.0.so - not found
===>   gtk2-2.24.29_2 depends on shared library: libcups.so - not found
===>   cups-2.1.4 depends on shared library: libavahi-client.so - not found
===>   avahi-app-0.6.31_5 depends on shared library: libdbus-glib-1.so - not found
===>   dbus-glib-0.104 depends on shared library: libdbus-1.so - not found
===>   dbus-1.8.20 depends on executable: xmlto - not found
===>   xmlto-0.0.28 depends on executable: w3m - not found
===>   w3m-0.5.3_5 depends on shared library: libgtk-x11-2.0.so - not found
===>   gtk2-2.24.29_2 depends on shared library: libcups.so - not found
===>   cups-2.1.4 depends on shared library: libavahi-client.so - not found
===>   avahi-app-0.6.31_5 depends on shared library: libdbus-glib-1.so - not found

It seems devel/dbus requires xmlto to install MANPAGES and xmlto itself requires dbus.
Comment 1 Walter Schwarzenfeld freebsd_triage 2018-01-12 11:02:07 UTC 
Maintainer feedback?
Comment 2 Walter Schwarzenfeld freebsd_triage 2018-03-05 01:43:53 UTC 
I think the dependency of xmlto on w3m is not necessairy
(configure --help: --with-webbrowser=[w3m|lynx|links|any]).
The questions is needs xmlto a browser?
Comment 3 Ting-Wei Lan 2018-03-08 13:49:01 UTC 
(In reply to w.schwarzenfeld from comment #2)
I guess that xmlto needs it because it wants to hard-code the path to w3m in the generated script during the build. I don't know what is the best solution, but I think installing w3m without INLINE_IMAGE option is a simple workaround. After xmlto is installed, you can rebuild w3m with INLINE_IMAGE option.

Since xmlto uses autotools to build, it may be possible to pass the path to w3m to the configure script from command line to override the check result of configure and move w3m to RUN_DEPENDS. But this still looks like a workaround ...
Comment 4 Walter Schwarzenfeld freebsd_triage 2018-03-08 15:14:07 UTC 
And why not lynx instead of w3m?
Comment 5 Ting-Wei Lan 2018-03-08 15:58:14 UTC 
(In reply to w.schwarzenfeld from comment #4)
I don't know why the maintainer picked w3m instead of lynx, but switching to another web browser still looks like a workaround. If a future version of lynx gains an optional feature which causes it to have an optional dependency on a graphical toolkit, the same dependency loop problem will happen again.
Comment 6 Walter Schwarzenfeld freebsd_triage 2019-08-13 15:10:34 UTC 
What if remove avahi from cups?
Comment 7 Ting-Wei Lan 2019-08-19 11:27:28 UTC 
(In reply to Walter Schwarzenfeld from comment #6)
Does the problem still exist? devel/dbus has switched to minixmlto in ports r425586, so building dbus should no longer pull in w3m.
Comment 8 Walter Schwarzenfeld freebsd_triage 2019-08-19 11:41:36 UTC 
You are right. Fixed with ports r425586.