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
reasons, see . However, it wouldn't necessarily be a problem if we
just did such changes on the regular fedora packages too, as a
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.
(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)