dependency loop in editors/vim with GTK3 option

[Adam Weinberger]

On Sat, Dec 15, 2018 at 2:24 AM Scott Bennett <bennett at sdf.org> wrote:
>
>      There is a dependency recursion loop in the build process for editors/vim
> if one selects the GTK3 config menu option.  The only way I've found so far to
> get around this is to choose the GTK2 option instead.
>      With GTK3 selected, graphics/librsvg2 becomes a dependency, which, in
> turn, is dependent upon lang/vala.  lang/vala depends upon devel/dconf, which
> depends upon devel/gconf2.  devel/gconf2 depends upon graphics/graphviz, which
> depends upon lang/vala!  The recursion occurs there and was found by following
> the instructions in UPDATING for the upgrade to perl5.28 when using portmaster.
> The command shown in the instructions is "portmaster -f", so the -f forces all
> dependencies and dependent ports to be rebuilt.
>      As nearly as I can see, this dependency recursion loop breaks any port
> involving lang/vala when portmaster -f is used.  In the case of editors/vim,
> a usable workaround is to choose gtk2 instead of gtk3, but for many other
> ports, the perl upgrade's admonition to rebuilt ports that depend upon the
> perl library to omit -f when using portmaster while providing portmaster a
> *complete list* of all ports to be built.  Provided an acceptable version
> of lang/vala is already installed, it will be used, and the dependency loop
> gets skipped over because there is no need to build lang/vala.  Of course,
> if one does that, there is no guarantee that the resulting binaries installed
> for any of the ports in the recursion loop will function properly, given that
> they may be based upon obsolete versions of the other ports in the loop.

Hi Scott,

Thanks for the report. A dependency loop is certainly a distressing
appearance! It can occur when non-default OPTIONS are set, but should
never occur with default OPTIONS. So, first question: do you have
non-default OPTIONS for those ports?

That said---your dependency chain doesn't look right. For example,
lang/vala depends directly on graphviz, and there is no graphviz
configuration that could depend directly on vala. lang/vala does not
depend on dconf, and dconf does not depend on gconf2. Some of the
dependencies you listed are backwards (gconf2 depends on dconf, and
dconf depends on vala), but others don't look possible.

If you are able to re-trigger the dependency loop, a log would be
extremely helpful.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org