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)