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.
Maintainer feedback?
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?
(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 ...
And why not lynx instead of w3m?
(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.
What if remove avahi from cups?
(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.
You are right. Fixed with ports r425586.