https://svnweb.freebsd.org/ports?view=revision&revision=474173 rubygem update fails with portmaster caused of wrong order of build. Seems the rubygem needs the same build depends as run depends. see: https://lists.freebsd.org/pipermail/freebsd-ports/2018-July/113781.html
I don't know how much ports effected. But most needed for: rubygem-glib2 rubygem-gobject-introspection rubygem-gio2 rubygem-gdk_pixbuf2 rubygem-pango rubygem-gdk3 rubygem-gtk3 rubygem-atk may be also for rubygem-cairo-gobject rubygem-cairo
The RUN_DEPENDS list is for dependencies that need not be available or up-to-date during a port build, but only to execute the applications in this port (e.g. shells, interpreters). These lead to dependencies recorded in the package built from a port. If the port is manually installed, then run dependencies are checked in the install phase (after the port has been built and staged). Pure run dependencies need not be available when some port is built. Dependencies that are required to build a port are either BUILD_DEPENDS (if the test is for the existence of some binary, e.g. a compiler) or LIB_DEPENDS. These are made available (and upgraded by portmaster, if applicable) before port that depends on them is built. Since the rubygem ports declare their dependencies as RUN_DEPENDS only, it is correct to assume that they need by updated before the dependent port is built. Therefore, the actual problem is that there are dependencies on shared libraries, which are wrongly declared as run dependencies. The relevant excerpts from bsd.port.mk (somewhat sanitized for easier reading) are: RUN_DEPENDS: A list of "path:dir[:target]" tuples of other ports this package depends to run. The test done to determine the existence of the dependency is the same as FETCH_DEPENDS. This will be checked during the "install" stage and the name of the dependency will be put into the package as well. [...] LIB_DEPENDS: A list of "lib:dir[:target]" tuples of other ports this package depends on. "lib" is the name of a shared library. For dependencies on shared libraries provided by other ports, it is sufficient to specify those ports in LIB_DEPENDS, this will imply that those libraries will be registered as run dependencies in the generated packages. Examples of correct usage can also be found in many Uses/*.mk files.
usr/ports/Mk/Uses/gem.mk needs: BUILD_DEPENDS+=${RUN_DEPENDS}
BUILD_DEPENDS+=${RUN_DEPENDS} actually fixes the issue but I'm still not sure if it is the correct fix because the issue doesn't occur when `make install`. I observed the difference between portmaster and make install, stage-qa is the point. Isn't stage-qa showing false-positive error?
Created attachment 206774 [details] make-stage.log Hmm, not a bug of stage-qa itself. When installing rubygem-acme-client, make install perform installation with following order. * build acme-client * try to stage acme-client but faraday is not installed * build faraday * stage faraday * stage-qa faraday * install faraday * stage acme-client * stage-qa acme-client * install acme-client portmaster doesn't install faraday before staging. It is an order issue. I'm not sure why and where this order difference come from.
You can insert -V RUN_DEPENDS in line 2314 in portmaster (it is then the same as ${BUILD_DEPENDS}+=${RUN_DEPENDS} in gem.mk) 2312 all-depends-list|build-depends-list) 2313 var_opt="$var_opt -V PKG_DEPENDS -V EXTRACT_DEPENDS \ 2314 -V PATCH_DEPENDS -V FETCH_DEPENDS -V BUILD_DEPENDS \ 2315 -V RUN_DEPENDS -V LIB_DEPENDS"
(In reply to Walter Schwarzenfeld from comment #6) That's looks the correct fix to me. Stefan, what do you think about that?
Created attachment 206783 [details] svn-diff-portmaster Includes another small change for bug #235793.