I'm not really found of this decision from a pure developer experience perspective. What would make Mir special compared to other system libraries, like libsystemd, pulseaudio, evolution-data-server, your email service libs, and so on and so on?
Sure, we can separate all of them, but we are back in the deb world, which is exactly what we want to avoid with snap. Also, changing all existing snaps for that change really shows something isn't coorrect. It will mean that every applications that depends on mir-libs needs to declare an additional plug, create an empty directory and so on… I guess a better solution to pave the way forward is either: - get a version and stable ABI/API between the libs and the server (or this won't work on the long term anyway). - get that transparently transition for applications. Meaning, the content ubuntu-app-platform interfaces still ship the Mir functionality. However, this could be done either directly or via another content interface snap. It may needs some upstream development. Please discuss those changes on the snapcraft mailing list to not only base on my opinion. -- 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
