LD_LIBRARY_PATH values are inconsistent when working with others

[Michael Terry]

Here's my situation:

Some coworkers and I are working on a unity8-session snap. We have a silo with some fixes and it's connected to a snap recipe that builds the occasional on-demand snap. The snap is supposed to be built with xenial+overlay+silo.

I was seeing some inconsistent behavior with other people that built their own snap. And I was seeing inconsistent behavior with other people that downloaded the silo snap.

It turns out that snapcraft inserts some LD_LIBRARY_PATH values in the command-*.wrapper scripts based on how the build system is set up. (right?) Those differences between coworkers and the silo meant that some things were broken based on whose snap was being used, despite everything else being the same.

Needless to say, that's annoying. Ideally we'd all be building "clean" snaps (as close to silo as possible).

There's a "snapcraft cleanbuild" option. I'm not super familiar with it, but I'm guessing it would take some manual work to configure the lxd instance with xenial+overlay+silo. And might be harder to iteratively build too?

Another option would be to let us build a snap without the special wrapper sauce?

Or maybe just making sure that stage-packages are also used as build-packages (so that the silo build would also know about the extra LD_LIBRARY_PATHs from the system)?

I'm not sure what the solution is necessarily. And I'm not even sure I've accurately diagnosed the problem. But the inconsistent experience felt annoying for a packaging format that is supposed to smooth out system differences.

[Joe Talbott (joetalbott)]

Do you have an example I can play around with?

[Michael Terry (mterry)]

These were some of the paths that snapcraft was (optionally) including in the wrapper, based on what the developer had installed:

export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/libunity:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/NetworkManager:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/oxide-qt:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/pulseaudio:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/qt5/libs:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/ubuntu-system-settings:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$SNAP/usr/lib/pulse-8.0/modules:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$SNAP/usr/lib/telepathy/gabble-0/lib:$LD_LIBRARY_PATH

I ended up just putting them all in our own wrapper. So problem avoided for now. It was just confusing for a bit when we couldn't tell why the snap built in the silo wasn't like the snaps we built locally.

[Michael Terry (mterry)]

My point being that I don't have a ready example (we worked around it in our snap). But it should be easy to generate by having a snapcraft.yaml that would trigger the above paths.

Like a part with stage-packages: [ubuntu-system-settings] for example.

[Sergio Schvezov (sergiusens)]

El 16/11/16 a las 15:07, Michael Terry escribió:
> My point being that I don't have a ready example (we worked around it in
> our snap). But it should be easy to generate by having a snapcraft.yaml
> that would trigger the above paths.
>
> Like a part with stage-packages: [ubuntu-system-settings] for example.
>
The solution IMO is to not conflate LD_LIBRARY_PATH we generate with the
one from the machine built and only include the ones we control.

[Joe Talbott (joetalbott)]

Are those paths build time or runtime paths? Are those paths needed for the snap's app(s)? Are the paths included when the dependency is already installed on the builder's system versus being installed during the 'stage-packages' handling code?

Sorry for all the silly questions, I just want to make sure I understand the issue.

[Joe Talbott (joetalbott)]

Sergio,

Are you referring to the code in prime() where we're adding system_dependency paths? I'm not certain if the problem is that _find_dependencies() is finding the wrong dependencies (i.e. NetworkManager, pulseaudio - which are dependencies of dependencies of a stage-package).

[Michael Terry (mterry)]

Joe, I'm sorry. For some reason, I'm not getting the emails from this bug.

> Are those paths build time or runtime paths?

Runtime paths.

> Are those paths needed for the snap's app(s)?

Usually.

> Are the paths included when the dependency is already installed on the builder's system versus being installed during the 'stage-packages' handling code?

They are only included when the dependency is already installed on the builder's system.

(This is a snapcraft feature, this isn't something I'm doing myself. Snapcraft does some ldd logic or something on the binaries.)

==

@sergio, you said "The solution IMO is to not conflate LD_LIBRARY_PATH we generate with the one from the machine built and only include the ones we control." -- I don't follow.