APP_ID is up to you. If it doesn't make sense, that's fine. The nice
thing about the APP_ID is that it is used with apps and its value also
corresponds to what is used in application lifecycle and application
isolation (it is the profile name). It might be nice to continue this
line of thinking into scopes, but like I said, if it isn't useful, I
don't have a problem with not including it.
I'm not sure I understand this statement: "I don't think there is any
point in adding <click-install-dir>/lib to LD_LIBRARY_PATH because a
scope can't install anything there." Click packaging is quite simple and
is simply an archive file to unpack and some metadata (the click
manifest and any corresponding files to support its declared click
hooks). As such, a click can contain executables, libraries, data files,
etc and a click install will simply unpack whatever is in the archive
file into the <click install directory>.
As such, I do think PATH and LD_LIBRARY_PATH should be set since scopes do have
execute and mmap permissions on things in their install install directory per
this rule:
@{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/** mrklix,
Like scopes, apps may not be expected to execute (or even mmap) things
from their install directory, but blocking that seems artificially
limiting for developers, so we allow it. Adjusting the PATH and
LD_LIBRARY_PATH in the way I described makes it so that application
developers don't have to jump through hoops or hardcode click install
paths in their code.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1327426
Title:
scopes runner should set various confinement variables
To manage notifications about this bug go to:
https://bugs.launchpad.net/unity-scopes-api/+bug/1327426/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
