Snappifying a big toplevel program

[Mark Shuttleworth]

Hi Michael

Unity8, LightDM and of course Mir itself are more likely to be
"frameworks" than plain apps. In a very real sense, they provide
services to other apps, so the framework designation is appropriate. Mir
provides "windows as a service", lightdm provides "authentication at the
GUI" as a service, unity8 provides app launch and switch and indicators
etc, as services.

Frameworks are definitely more complex to produce. So I'd suggest
narrowing the scope down to, say, a single GUI application. Imagine, for
example, a device like a Crestron home controller with a touch screen.
It needs to boot up and then cleanly launch just that single
application. Perhaps it would need authentication ("log in before you
turn off all the electricity) which is what lightdm might provide to it,
but in many cases it will just deliver the goods (most often you don't
need a password to dim the lights :).

Conducting the thought exercise you mapped out, but for a single complex
GUI app like a home controller, might be a more straightforward place to
start.

Mark


On 20/02/15 22:21, Michael Terry wrote:
> 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: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150222/373db566/attachment.html>