Commit 58a54723 authored by Simon McVittie's avatar Simon McVittie

Add notes about how much of Application Layout has been implemented

Reviewed-by: default avatarMathieu Duponchelle <>
Signed-off-by: default avatarSimon McVittie <>
Differential Revision:
parent c64c99ab
......@@ -631,6 +631,12 @@ variables, so that they automatically use appropriate directories:
**Unresolved:** [](#should-ld_library_path-be-set)
This is automatically done by `canterbury-exec` in Apertis 16.06 or later,
unless the entry point's bundle ID cannot be determined from its `.desktop`
file. For backwards compatibility, Canterbury in Apertis 16.09 still attempts
to run entry points whose bundle ID cannot be determined, but this should
be prevented in future.
Built-in application bundles should be given the same environment
variables, but with `/usr/Applications` replacing `/Applications`.
......@@ -656,6 +662,9 @@ for both built-in and store application bundles:
* `g_get_user_special_dir (G_USER_DIRECTORY_VIDEOS)`:
Again, this is automatically done by `canterbury-exec` in Apertis 16.06 or
### Permissions and ownership
All files under `/usr/Applications` and `/Applications` should be owned
......@@ -680,7 +689,8 @@ other words, only accessible by the owner or by root).
### Installation and upgrading
Suppose we are installing `com.example.MyApp` version 2, or upgrading
it from version 1 to version 2. That would look something like this:
it from version 1 to version 2. An optimal implementation would look
something like this:
* If it was already installed:
* Instruct any running processes belonging to that bundle to exit
......@@ -721,9 +731,11 @@ A simpler procedure would be to create the `com.example.MyApp/version-2/static`
subvolume as empty, and then unpack all of the static files from the
new version. However, that procedure would not provide de-duplication
between consecutive versions if a file has not changed.
As of Apertis 16.09, only this simpler procedure has been implemented.
Ribchester (and perhaps Canterbury) must be modified to create the
per-user directories `/var/Applications/$bundle_id/users/$uid`.
per-user directories `/var/Applications/$bundle_id/users/$uid`. This
was implemented in Apertis 16.06.
#### Store application system integration links
......@@ -917,6 +929,9 @@ bundles like `G_USER_DIRECTORY_MUSIC` and `G_USER_DIRECTORY_VIDEOS`, or
should it be per-user like `$HOME`, or should it be per-user per-bundle
like `g_get_user_cache_dir()`?
As of Apertis 16.06, it has been implemented as shared, like
### What is the scope of `DESKTOP`, `DOCUMENTS`, `TEMPLATES`?
What should the scope of `G_USER_DIRECTORY_DESKTOP`,
......@@ -924,6 +939,9 @@ What should the scope of `G_USER_DIRECTORY_DESKTOP`,
we declare these to be unsupported on Apertis, and set them to the same
place as `$HOME` as documented by their specification?
As of Apertis 16.06, these were marked as unsupported and set to be the
same as `$HOME`.
## Unresolved implementation questions
### Can we prevent symlink attacks in shared directories?
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment