Fedora runtimes and sandboxed desktop applications
Owen Taylor
otaylor at redhat.com
Thu May 28 16:43:57 UTC 2015
On Wed, 2015-05-27 at 11:50 +0200, Alexander Larsson wrote:
>
> Packaging an application also requires some changes other than the
> relocatability itself. First of all, all "exported" files from an
> application (such as icons, desktop files, dbus service files, or
> other files that are read from outside the app itself) must have the
> application id (which is a dbus/java-style reverse dns name) as a
> filename prefix. This is both for avoiding conflicts, and for
> security
> reasons, see [4]. However, it wouldn't necessarily be a problem if we
> just did such changes on the regular fedora packages too, as a
> regular
> fedora packaging policy.
>
> One issue is that as third party packagers of applications we should
> not use the "official" app ids for our builds, as they would conflict
> with upstream doing their own release. So, our package of
> org.gnome.gedit should probably be called org.fedoraproject.gedit,
> which may require some minor tweaks to the build (for instance, this
> affects the dbus name the app uses for dbus activated desktop files,
> as well as the name of the desktop file itself).
Thanks for sharing your work! It's definitely very interesting how a
Fedora runtime can be used to bootstrap the process of getting to a
place where applications are bundled and sandboxed.
Is changing the app-id right? To me, app IDs correspond to application
identity. If a user has a Fedora version of GEdit installed, and then
installs a newer version of GEdit from upstream, I would expect:
- Only one GEdit icon appears in the list of applications
- If the user marked GEdit as a favorite, the favorite icon
retargets to the newer installed version
By using the name GEdit and the GEdit icon, Fedora has already made the
claim *to the user* that what it packaged is GEdit - having a different
application ID under the hood can only lead to confusion.
- Owen
(Changing the application ID is a bit like the fedora- vendor prefix we
were adding to desktop files, which was a big pain to unwind)
More information about the desktop
mailing list