Comment 2 for bug 1663048

The conclusion on the email thread seemed to be to enforce the use of mir-libs by any applications that want to run that way, and for unity8 to also use mir-libs.

per mterry:

One additional wrinkle here is that you probably also want to recommend to clients that they put the mir-libs path first in LD_LIBRARY_PATH.

It's easy to accidentally include libmirclientX in a snap through stage-packages dependencies. So whatever documentation you have around "you must use mir-libs" (which should already mention the need to include the mount path from mir-libs in LD_LIBRARY_PATH at all) should also mention that it should probably go first in that list.

The trick then is that mir-libs is now overriding all the mir-dependant libraries from the client snap. Things like glib, boost, etc. So your documentation should probably also include that possibility and mention that they can instead put mir-libs paths at the END of LD_LIBRARY_PATH, but they have to then add some logic to snapcraft.yaml to exclude the mir libraries out of their snap, in case they have them there.

This can be somewhat mitigated by making the mir-libs content snap as minimal and isolated as possible