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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1663048 Title: libmirclient in snaps gets out of sync with archive To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1663048/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
