Comment 12 for bug 1663048

Didier, I mostly agree with you, but you are missing the context and meetings that led to this approach. I'm just the messenger here, and anyone please correct me if I mess something up.

- The Mir team is actively working on a stable ABI 1.0 release. That's coming in short term (but will involve an ABI change when it lands).

- The Mir team is so-far uninterested in providing a stable socket protocol, certainly in the short or medium term. (Preferring instead to say the library is the interface.) This isn't a very snappy approach, granted. But it's been the approach they've used in the archive for a while.

- *IF* the Mir team says "using a content snap is the only supported way", we really don't want to make that content snap be u-a-p. Partly because there are Mir clients that don't care about the rest of u-a-p (GTK has a Mir backend for example). And partly because all the issues around LD_LIBRARY_PATH and library content snaps (which is sort of a nightmare that just hasn't happened to bite us yet) make it advantageous to strongly limit the scope of an always-required content snap.

- I agree in theory Mir is not different than those other system libraries. Except that those system libraries tend to have a more stable library and protocol interface policies. Policies that mean the interface can survive the lifetime of a Core series (which is all that we care about, right?). But Mir is not able to make such promises yet.