Maybe all libreoffice ports have a cyclic dependency on themselves.

Comment 2 Dima Panov 2022-08-19 11:33:53 UTC

This is not a libreoffice failure but portmaster itself. please ping portmaster maintainer.

Hi Stefan,

Could you please have look at this?

-- Martin

Comment 4 Stefan Eßer 2022-08-19 14:56:17 UTC

(In reply to Martin Birgmeier from comment #3)

This is a common issue if a port has a run dependency that is required to stage or package the port, but which is not declared as a build dependency.

Portmaster is more strict than poudriere with regard to different types of dependencies. When building with poudriere, all RUN_DEPENDS are installed into the build jail before a port build starts.

Portmaster builds and installs BUILD_DEPENDS and LIB_DEPENDS before working on the respective port that declares these dependencies, but installs RUN_DEPENDS only after completing the port build.

The basic ports system does not perform the same kind of dependency checking as either portmaster or poudriere does. It just recurses into dependent ports for each target before invoking the target on the port itself - thus is recursively calls "make install" on all dependencies (including RUN_DEPENDS) before installing the port itself. The reason is simply that make works on sub-goals before main-goals, and the installation of dependencies is a sub-goal that has to be completed before the main-goal may be attempted. (If the order was reversed and the installation of the port succeeded but the installation of a RUN_DEPENDS port failed thereafter, calling "make install" would find the port being installed and would not make another attempt to install the run dependencies).

You can use "portmaster -t" to force portmaster to provide RUN_DEPENDS before building a port, but that can result in much overhead and can cause dependency loops.

If a RUN_DEPENDS target is required before a port can be staged or packaged, then it actually is a build dependency and should be declared as such.

Thank you for the detailed explanation, even though I must admit to not fully understanding it.

Something must have changed in either portmaster or the libreoffice ports a few months ago, resulting in the behavior described in this ticket and also in bug #265936.

I have noticed that for the libreoffice ports I am using, portmaster first builds, e.g., german/libreoffice, then uninstalls the old version of this port, then notices that it needs to upgrade editors/libreoffice as a (presumably runtime) dependency, then builds that one and tries to install it. But that fails because the old version is already installed. The result is that german/libreoffice remains deinstalled after this failure, the old editors/libreoffice remains installed, and the build directory contains a readily built new editors/libreoffice.

It seems to me that if portmaster detects such a kind of runtime dependency where the depended-on port needs to be upgraded, it should first perform the upgrade of that port before proceeding to the upgrade of the depending port (in this case, german/libreoffice).

This seemingly inverted dependency order is also visible in the output of the first scan portmaster performs, before it is asking whether to continue (if not using --no-confirm): The depended-on ports are listed after the depending ports when it would seem more logical to invert this.

-- Martin

p.s. It is also visible in the following command I am using to watch the progress of portmaster:

ps -axuewww | sed -n 's/.*PM_NEEDS_UPDATE= //p' | sort -u | tail -1 | sed 's/ /\
/g' | sed '/^$/,$ d' | less

Not fully functional but still helpful.

(In reply to Martin Birgmeier from comment #5)

In portmasterfail.txt one can also see the "inverse" ordering of dependencies.