Snappifying a big toplevel program

[Loïc Minier]

On Mon, Feb 23, 2015 at 6:29 PM, Michael Terry <michael.terry at canonical.com>
wrote:

> Ouch.  LD_LIBRARY_PATH doesn't cover much, as I mentioned in my first
> email.  Libraries & scripts often call outside executables with a full
> path.  And any data files referenced by libraries/programs tend to have
> full paths determined at compile time too.  Which means relying on
> LD_LIBRARY_PATH or PATH doesn't buy you much.
>

It's indeed an issue at a large scale, but perhaps it's manageable if it
covers a limited subset of packages we change to take a configurable
runtime pathnames; would you know how many packages are we speaking of?


> What are the SNAPPY_* vars?  (Sorry for newbie questions, I'm coming into
> snappy rather fresh, and all the docs I've seen
>

here are some specific pathnames your app can use for persistence and which
are set in the environment:
- $SNAPP_APP_PATH contains the base of your installed app (typically static
files)
- $SNAPP_APP_DATA_PATH contains the writable directory for your app
- there's also a per app, per user directory




> So maybe there is room for LD_PRELOAD path-redirection after all,
> especially if overlays are a no-go on the phone.  Unless there are
> objections that I'm wasting my time, I'm going to investigate that.
>

Yes; that could work. There are some limitations there too, but perhaps
it's a more sensible short-term approach when we control the programs
somewhat. I believe scratchbox2 or scratchbox-ng had a relatively generic
implementation with redirection rules in lua or some other high level
config/scripting language.

Cheers,
-- 
Loïc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150224/48657e69/attachment.html>