ubuntu-desktop-installer LD_LIBRARY_PATH not defined anymore

[Sebastien Bacher]

Perhaps a 8.0.1 regression but our desktop installer snap (which is classic) stopped working, getting into the shell environment LD_LIBRARY_PATH isn't set anymore.

For reference our source is on https://github.com/canonical/ubuntu-desktop-installer/blob/main/snap/snapcraft.yaml

A 10 days old build didn't have the issue so maybe a 8.0.1 regression?

[Sebastien Bacher (seb128)]

In case that's more descriptive, installing a recent build, then reverting to the revision currently in the stable channel of the store

$ snap run --shell ubuntu-desktop-installer
$ env | grep LD_
$

$ sudo snap revert ubuntu-desktop-installer
ubuntu-desktop-installer reverted to 0+git.4edfab2b

$ snap run --shell ubuntu-desktop-installer
$ env | grep LD_
LD_LIBRARY_PATH=/var/lib/snapd/lib/gl:/var/lib/snapd/lib/gl32:/var/lib/snapd/void:/snap/ubuntu-desktop-installer/1278/lib:/snap/ubuntu-desktop-installer/1278/usr/lib:/snap/ubuntu-desktop-installer/1278/lib/x86_64-linux-gnu:/snap/ubuntu-desktop-installer/1278/usr/lib/x86_64-linux-gnu

[Sergio Schvezov (sergiusens)]

This is most likely the bug fix to not do this anymore which we introduced in 8.x to not break people relying on this when building with 7.x.

The reason this is bad is for the case where your classic confined snap shells out to a command provided by the host, for which case it will pick up libraries provided by the snap instead of those on the host.

[Sebastien Bacher (seb128)]

Thanks for the explanation, it's a bit unfortunate because it's an incompatible change and is breaking working snaps on simple rebuilds and not notifying the developers of a potential issue...

Our snap is crafted to use binaries from the snap and provides compatible versions of the libraries, is there a flag/way to restore the previous behavior?

I think any incompatible change to the tools should be an opt-in/behind some sort of flag to enable the new default...