It turns out that live apps were exporting files with dashes
other than "-symbolic". For instance "org.libreoffice.LibreOffice" was
exporting "org.libreoffice.LibreOffice-writer.desktop".
Allowing any dashes in the last segment like this is really no diffent
than allowing org.libreoffice.LibreOffice.writer.desktop which we
already do. Any conflicts here are under the control of the owner
of the org.libreoffice prefix.
However, allowing dashes in the earlier segments is more problematic.
For instance, any file exported by "org.my-foo.App" could conflict with
an app called "org.my" if this was allowed.
So, as a middle ground, we're allowing dashes in the last segment of
the App id only.
For a long time we have been disallowing "-" in application names,
which is different than what dbus allows for bus names. Also "-" used
to be not allowed by GApplication in glib. This is in part because
dbus object paths do *not* allow dashes, so you can't legally map
from e.g. a valid name like "org.foo-bar.gazonk" to a valid path
like "/org/foo-bar/gazonk".
This is a problem because many existing apps already use "-" in the
name, either as the last part (org.gnome.font-viewer) or because
the dns name it refers to has a dash.
This was recently discussed in the dbus community, and the result
is to recommend that "-" in the bus names be converted to "_" in object
paths.
This change makes it also allowed to have "-" in a flatpak app id.
For flatpak specifically we were relying on "-" not being allowed to
handle the case of exporting "org.foo.App-symbolic.png". If "-" is
allowed this name can conflict between apps called "org.foo.App-symbolic"
and "org.foo.App".
To handle this we add two special cases:
* App ids can't end with "-symbolic".
* Apps are allowed to export files with $appid-symbolic as prefix.
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
If there are multiple refs pointing to the same revision, then
collecting the size and metadata info for each of them is wasteful.
Maintain a hash table of the data so that it's only collected once per
revision.
This slightly widens an existing race where a ref could be updated
before the summary file is regenerated. In that case, the data in the
xa.cache variant would correspond to the wrong revision. I don't believe
this can be fixed unless there's locking at the ostree level.
If there are non-flatpak refs in the ostree repo, there's no use in
collecting size or metadata information for them. Instead, only operate
on refs in the appstream, app or runtime prefixes.
The commands: install, update, uninstall, info, make-current and run
now supports specifying a partial ref for the name. This is a different
way of specifying optional arch and branch arguments.
For instance org.app.App//master is the same as "org.app.App master" or
"--branch=master org.app.App".
This is useful if you're cutting and pasting from e.g. the list -d output.
Missing icons are now only visible in verbose logs, and we don't
print warnings about missing appdata for runtimes (such as locale
and debug extensions).
This replaces all current callers of gs_file_ensure_directory with
equivalent code.
Actually, two instances were calling gs_file_ensure_directory with
FALSE, i.e. error out on EEXIST, but those cases seem fine with the
do-nothing-if-exists semantics.
This commit makes flatpak print a debug message (which only appears to
the user if the -v option is used) whenever a subprocess is launched.
This should make debugging easier, both for flatpak users and
developers.
When trying to extract icons to regenerate the appstream, we are looping
over the entire file every time, instead of only trying to copy icons
for the application ID we're looking at the moment.
This is most likely benign, but it causes a lot of "Error copying icon:
No such file or directory:" spew when calling flatpak build-update-repo.
Alexander Larsson