Snappifying a big toplevel program

Michael Terry michael.terry at
Fri Feb 20 20:21:57 UTC 2015

So I was thinking about the problem of snappifying a complex top-level
native program like unity8 (all the way down to Ubuntu Core, as one giant
snappy package).

Unity8 requires a lot of dependencies with their own libraries,
executables, and data files to function.  I don't want to recompile all of
them to install into snappy-friendly paths, so I was thinking of how best
to suck their existing files into a snappy bundle.

= Libraries =
Not all libraries in Ubuntu are offered as static libraries, which would be
one way to go.  But we can link to copies of the .so files in non-standard
locations with LD_LIBRARY_PATH just fine.

= Executables =
PATH mangling can help here.  But for various reasons (security, not
assuming anything about PATH), many libraries or scripts use full paths,
which is a problem.

= Data =
It's typical for these to be specified by full path at compile time,
unfortunately.  Not much we could do there.

= Solutions =
(Do you folks have a standard solution for such lookup problems? I'm not
super familiar with the sate-of-the-art.)

I was thinking it might be easy enough to slurp all of unity8's
dependencies into a fake filesystem tree, then use LD_PRELOAD tricks to
prefer the snappy paths if they exist, falling back to the system files.
(for reading, writing could just directly use system paths)

In addition to the path redirection, I would also probably have to override
exec() and friends to propogate LD_PRELOAD in case the environment got
scrubbed before calling an executable.

I already have proof-of-concept code inside lightdm's test code that does
such path redirection suitable for lightdm's needs.  But is this a fool's
errand, to do this on a larger scale?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the snappy-devel mailing list