<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 6:29 PM, Michael Terry <span dir="ltr"><<a href="mailto:michael.terry@canonical.com" target="_blank">michael.terry@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>What are the SNAPPY_* vars?  (Sorry for newbie questions, I'm coming into snappy rather fresh, and all the docs I've seen</div></div></div></div></blockquote><div><br></div><div><div style="font-size:12.8000001907349px">here are some specific pathnames your app can use for persistence and which are set in the environment:</div><div style="font-size:12.8000001907349px">- $SNAPP_APP_PATH contains the base of your installed app (typically static files)</div><div style="font-size:12.8000001907349px">- $SNAPP_APP_DATA_PATH contains the writable directory for your app</div><div style="font-size:12.8000001907349px">- there's also a per app, per user directory</div></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>-- </div><div>Loïc</div></div></div></div>