debian: do not ship /etc/ld.so.conf.d/snappy.conf (LP: #1589006)

[mvo5]

This avoid the "mount point busy" error on uninstalling the nvidia-361 deb.

[zyga]

LGTM though I'd love to see a comment in the code (so that it doesn't get lost easily) that says how this fixes the problem and what the problem originally was

[niemeyer]

Couple of questions:

How was the mount point being kept busy by simply adding this to ld.so.conf?

How will applications work now that this is not in the search path?

[mvo5]

@niemeyer Thanks for your review. To answer your questions:

a) The mount point is kept busy because the libGL.so is loaded from /var/lib/snapd/lib/gl now instead of from/usr/lib. Here is the output oflsof -p $(pidof glxgears)` with 2.0.6:

glxgears 3069 mvo  mem    REG               8,18   579760  6307148 /var/lib/snapd/lib/gl/libGL.so.1.0.0

With snapd_2.0.7 and lddconfig (to ensure the dir is fully gone from the cache):

glxgears 3997 mvo  mem    REG               8,18   579760  6307148 /usr/lib/nvidia-361/libGL.so.1.0.0

Compiz will of course also open this library.

b) Right now the snaps will have to set LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH? in their wrappers. This is needed currently anyway because usually snaps like krita ship a copy of mesa in their tree and use it LD_LIBRARY_PATH. So they need to have something likeLD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$SNAP/usr/lib/mesaso that nvidia is first in the search path. Later we can use the newsnap run/snap-exec` to ensure that the path is setup correctly.

So while this branch is needed to unblock things I wonder if we should change the strategy for the mounting of the nvidia directoy. Instead of using the bind mount unit that is visible systemwide we could go back to change the launcher and only setup the bind mount for snaps in their mount namespace (so hidding this mount from the host system view). the downside is added complexity for the launcher: https://code.launchpad.net/~mvo/ubuntu-core-launcher/auto-bind-mount-nvidia/+merge/291983

[niemeyer]

As we discussed today in the meeting, I think we should go ahead with the bindmount security backend, and have an elegant path for handling this and the many other similar cases we'll find (fonts, themes, etc).