circular build-dependency between mesa, mir

[Steve Langasek]

While testing cross-building of mir, I noticed that mir and mesa have a build-dependency loop: installing the build-dependencies of mir installs libmirclient-dev.

This is because mir build-depends on libegl1-mesa-dev, and libegl1-mesa-dev depends on libmirclient-dev.

The libegl1-mesa runtime package does *not* depend on libmirclient3, so this dependency looks spurious to me. Is there a reason this dependency loop shouldn't be broken by dropping the dep from libegl1-mesa-dev -> libmirclient-dev? As near as I can tell, the dependency on libmirclient-dev is because of this section of /usr/include/EGL/eglplatform.h:

#elif defined(MIR_EGL_PLATFORM)

#include <mir_toolkit/mir_client_library.h>
typedef MirEGLNativeDisplayType EGLNativeDisplayType;
typedef void *EGLNativePixmapType;
typedef MirEGLNativeWindowType EGLNativeWindowType;

[...]

But that's optional, and anybody defining MIR_EGL_PLATFORM would presumably need to depend on mir themselves, no?

[kevin gunn (kgunn72)]

alf - since you've been digging around platform is this something that could easily be addressed ?
or has this already been cleaned up ?

[Daniel van Vugt (vanvugt)]

Duplicate of bug 1192908, but forgive me for forgetting the exact details.

[Alexandros Frantzis (afrantzis)]

This bug is still valid. We don't have a problem at this point, because we have both mir and mesa packages in the archive, so we can build new versions using the existing versions of -dev packages to fulfill dependencies (this needs some care when we make incompatible changes).

I agree that our best way forward is to remove the dependency libegl1-mesa-dev has on libmirclient-dev. It's reasonable to assume that a program that needs to use Mir with EGL will depend on libmirclient-dev itself, or at least mircommon-dev (otherwise how can it know about the MirConnection/Surfaces types it needs to pass to EGL?).

I would also recommend changing mesa to build-depend on mircommon-dev instead of the full libmirclient-dev, since it only needs the Mir EGL definitions in the former package.

Note, though, that as Daniel points in bug #1192908, we have a circular dependency issue at the source package level, that can't be solved unless we either use multiple source packages for Mir, or move our Mir Mesa EGL definitions upstream in Mesa, as Kevin suggested.

[Daniel van Vugt (vanvugt)]

The older bug 1192908 has a fix that landed (and was later deprecated). So to avoid confusing the situation I've reopened this bug for the work to happen in.

[Timo Aaltonen (tjaalton)]

Mir EGL platform is gone