Buildbot fails incorrectly if calculated dependency tree becomes invalid during installation

[ryandesign (Ryan Carsten Schmidt)]

​Build 5636 failed:

port gnuradio +docs+grc+jack+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui fd2146872b399e4f5b215d6a9eb31e6523aa1f444c9855cede444c86829b1078 previously failed in build https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/5623
Dependency 'gnuradio' with variants '+docs+grc+jack+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui' has previously failed and is required.

But in ​build 5623, the reason why gnuradio failed was:

Error: Unable to execute port: Can't install gnuradio because conflicting ports are active: gnuradio-devel
Build of dependency 'gnuradio' with variants '+docs+grc+jack+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui' failed, aborting.

Not sure why both gnuradio and gnuradio-devel were in the dependency tree, but the fact that gnuradio failed because gnuradio-devel was active shouldn't disqualify gnuradio from being built in the future.

[neverpanic (Clemens Lang)]

Build 5623 of gnss-sdr-devel should not have failed, because at the point where gnuradio was required by gr-osmosdr, gnuradio-devel was already installed and would have satisfied the dependency of gr-osmosdr. The problem is that at this point, we no longer know that gr-osmosdr would accept the already-installed gnuradio-devel, because we run dependency calculation first and then just stupidly iterate over the list.

A solution for this problem might be complicated… basically, while iterating over the dependency tree and before installing a specific dependency, we'd have to check whether the port(s) that require(s) the current dependency still need it or the requirement has been satisfied using other means (e.g., a path:, lib:, or bin: dependency) meanwhile. This problem occurs more or less because we don't compute a closed form solution of the dependency tree before actually installing.

To reset the incorrect state for now, you can just trigger a build of gnuradio directly, which will ignore the failcache but update it on success.

[ryandesign (Ryan Carsten Schmidt)]

Replying to cal@…:

Build 5623 of gnss-sdr-devel should not have failed, because at the point where gnuradio was required by gr-osmosdr, gnuradio-devel was already installed and would have satisfied the dependency of gr-osmosdr. The problem is that at this point, we no longer know that gr-osmosdr would accept the already-installed gnuradio-devel, because we run dependency calculation first and then just stupidly iterate over the list.

A solution for this problem might be complicated… basically, while iterating over the dependency tree and before installing a specific dependency, we'd have to check whether the port(s) that require(s) the current dependency still need it or the requirement has been satisfied using other means (e.g., a path:, lib:, or bin: dependency) meanwhile. This problem occurs more or less because we don't compute a closed form solution of the dependency tree before actually installing.

I figured it was something tricky like this.

To reset the incorrect state for now, you can just trigger a build of gnuradio directly, which will ignore the failcache but update it on success.

Oh good, I didn't know that would work. I ran builds of gnuradio on all the builders, which succeeded on the recent OS versions at least.

[carlesfernandez (Carles Fernandez)]

Cc Me!