I'm working on an application sandboxing system called xdg-app, and the surrounding echo-system. I won't go into details, but there are some links to technical details at the end of the mail[1]. The basic idea is that we have two sources (both ostree trees), one called the runtime (/usr), and one called the app (/app), which get combined in a container-like environment at launch time by xdg-app, with configurable degrees of sandboxing. There is also some interaction with the host system so that installed desktop files show up in the shell and dbus session services from apps work.
xdg-app has two major goals, the first is to allow applications to run in a sandboxed environment with minimal access to the host. The second is to allow third parties to create and distribute applications that run on all distributions (and the sandboxing helps making this less risky). To facilitate and test this I've also created an upstream gnome runtime[2] that gnome applications can chose to use. I'm also working on various Portal APIs[3] that allow sandboxed applications to safely interact with the system.
But, third party applications are a long way off in the future, and so are sandboxed applications (which need not only a fleshed out set of sandbox APIs, but also modifications to individual apps). In the meantime it is still interesting to run bundled applications. For instance in the context of an Atomic-based Fedora Workstation (with readonly /usr), or if you want to run older or newer versions of applications than your distribution is shipping.
It would make a lot of sense to use the existing packages in Fedora for this. And in order to kickstart discussions about this I've created an initial sample of a possible Fedora runtime using rpm-ostree and the Fedora 22 repositories:
https://github.com/alexlarsson/fedora-runtime
Building this produces a repo with the main runtime (org.fedoraproject.Platform) and a sdk runtime (org.fedoraproject.Sdk) which has some additional tools for app creation and debugging. It also builds .Var subruntimes that contain /var with the rpm db for use when building apps. The current package set is mostly based on what is in the gnome one, so don't consider this official in any way.
These runtimes are made to work with xdg-app 0.3.0 which are now in updates-testing for F21 and F22. You also need rpm-ostree from git master for the container support to build the fedra runtime.
In order to test the runtime I've also created a firefox application bundle. Unfortunately it requires some hacks in order to be relocated to /app, and to work as a bundle. However, it works pretty well, running somewhat contained with only access to the Downloads xdg directory and with ~/.mozilla being redirected to the per-app persistant data directory (~/.var/app/org.fedoraproject.firefox). Note however, that I would not consider this properly sandboxed, as it uses X11 for rendering, which is not very secure.
The scripts to build the firefox bundle is here:
https://github.com/alexlarsson/fedora-apps
I've also put up a xdg-app repository so that you can easily test this: (Run these commands as non-root, due to the --user args)
xdg-app add-remote --user --no-gpg-verify fedora http://people.redhat.com/~alexl/repo xdg-app install-runtime --user fedora org.fedoraproject.Platform 22 xdg-app install-app --user fedora org.fedoraproject.firefox xdg-app run org.fedoraproject.firefox
Once installed the desktop file will be exported to the session, so you should also be able to launch it from the shell. In theory this should work on any distro, but I've only tried it on F21.
The question is, would the Fedora project be interested in supplying and maintaining a Fedora runtime like this, which allows us (and others) to create applications using the fedora base. And if we do, exactly what should be considered part of the basic platform.
Defining a platform requires a lot of care. It is a balance between wanting as much as possible in it to share more maintainance and updates and make it easier to write apps and on the other hand trying to keep the basic platfrom small, maintained and of high quality. The ABI requirements for a platform is a bit different than a regular distro. The goal is to allow apps built against a particular platform to run for years to come, so it should only do security and very important bugfix updates, and *never* break ABI. On the other hand, its easy to break ABI in a later version of the runtime, because they are parallel installed. This is somewhat different than our current updates which revs libraries during the distro lifetime as long as it also updates all users of it.
An added complexity is that anything in the runtime that relies on some kind of IPC to the host (say the pulseaudio client libraries, or something that uses a dbus interface on the host) requires the host side of that IPC to remain available and backwards compatible in future versions of the distro, so we should err on exposing a minimal set of IPC.
There is also some changes that may be required in the distro to keep unnecessary dependencies out of the runtime. For instance anything related to hardware or system initialization is completely unnecessary. Luckily much of this is being fixed by similar needs from docker already.
One thing that is different from docker however, is that we generally want translations/locales in the runtime. But these are pretty large, so we want to handle them in a smart way. xdg-app has a feature that allows splitting a runtime into a base and a set of optional extensions that are mounted in the sandbox only when they are installed. I use this in the gnome runtime to split out each locale. Unfortunately Fedora uses a single large locale-archive file for its locales, so its hard to do that. This needs some research to figure out how to do properly.
There are also some custom configuration that a runtime needs. For instance, the build script for the fedora runtime above drops in a new fontconfig file that adds a /app/share/fonts fontdir for app-bundled fonts and configuration to include the host fonts (which xdg-app exposes in /run/host/fonts). This would be nicer if this was just a fontconfig subpackage we could pull in, and I'm sure there are more similar configuration options that would be needed.
Creating applications from fedora packages is a bit more complicated. The primary reason is that they need to be relocated to /app. In the hacky script above I just extract the rpm contents to /app and then rewrite some rpaths and shell scripts. A less hacky approach is to rebuild the rpms with a different rpm %_prefix macro, or to use relocatable rpms. It is not really significantly different from creating rpms to use in software collections though, so we have some experience with this.
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).
There are clearly a lot of details here, but I'll stop here and throw this out as the start of a discussion. I'll gladly reply to any questions people may have.
[1] More information: My devconf talk: https://www.youtube.com/watch?v=t-2a_XYJPEY gnome wiki: https://wiki.gnome.org/Projects/SandboxedApps xdg-app code: https://github.com/alexlarsson/xdg-app
[2] Announcement of gnome runtime: https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-a...
[3] https://wiki.gnome.org/Projects/SandboxedApps/DocumentPortal https://wiki.gnome.org/Projects/SandboxedApps/Sandbox
[4] https://mail.gnome.org/archives/gnome-os-list/2015-February/msg00009.html
On Wed, May 27, 2015 at 11:50:15AM +0200, Alexander Larsson wrote:
I'm working on an application sandboxing system called xdg-app, and the surrounding echo-system. I won't go into details, but there are
Very interesting stuff! I know you've been working on this for a while and I'm glad to see it's gotten to the point where it's useful to bring here. :)
I probably have _more_ comments later, but a few random initial ones:
Defining a platform requires a lot of care. It is a balance between wanting as much as possible in it to share more maintainance and updates and make it easier to write apps and on the other hand trying to keep the basic platfrom small, maintained and of high quality. The ABI requirements for a platform is a bit different than a regular distro. The goal is to allow apps built against a particular platform to run for years to come, so it should only do security and very important bugfix updates, and *never* break ABI. On the other hand, its easy to break ABI in a later version of the runtime, because they are parallel installed. This is somewhat different than our current updates which revs libraries during the distro lifetime as long as it also updates all users of it.
This is definitely something I know that _users_ are interested in. The "*never*" part is hard, though, because it requires a commitment for the backporting of security patches, and although over the last year the Fedora Security Team has stepped up activity, we'd really wantto make sure we have the resources required to keep our promises long-term.
One thing that is different from docker however, is that we generally want translations/locales in the runtime. But these are pretty large, so we want to handle them in a smart way. xdg-app has a feature that allows splitting a runtime into a base and a set of optional extensions that are mounted in the sandbox only when they are installed. I use this in the gnome runtime to split out each locale. Unfortunately Fedora uses a single large locale-archive file for its locales, so its hard to do that. This needs some research to figure out how to do properly.
Yeah, because as you say translations inside Docker have been lower priority, most of the effort so far has been on just ditching them rather than the modularization this needs.
Creating applications from fedora packages is a bit more complicated. The primary reason is that they need to be relocated to /app. In the hacky script above I just extract the rpm contents to /app and then rewrite some rpaths and shell scripts. A less hacky approach is to rebuild the rpms with a different rpm %_prefix macro, or to use relocatable rpms. It is not really significantly different from creating rpms to use in software collections though, so we have some experience with this.
Let's figure out what's needed and get that into base RPM. I have been pretty clearly told by RH management that there's support for that as long as we have clear requirements and a sensible plan. I think one of the lessons learned from Software Collections is that the macro system used there turned out to be harder than it looks.
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.
Possibly this could be done automatically with the "/app-relocated" builds? I don't know offhand how popular / useful this would be as global 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).
I guess that makes sense as our package namespace is already flat. Maybe something like org.fedoraproject.pkg.gedit, to give room to do something different in the future? Ehhh, bikeshedding. :)
On ons, 2015-05-27 at 08:56 -0400, Matthew Miller wrote:
On Wed, May 27, 2015 at 11:50:15AM +0200, Alexander Larsson wrote:
The ABI requirements for a platform is a bit different than a regular distro. The goal is to allow apps built against a particular platform to run for years to come, so it should only do security and very important bugfix updates, and *never* break ABI.
This is definitely something I know that _users_ are interested in. The "*never*" part is hard, though, because it requires a commitment for the backporting of security patches, and although over the last year the Fedora Security Team has stepped up activity, we'd really want to make sure we have the resources required to keep our promises long-term.
I realize that "never break ABI" sounds scary, but that is what is what is needed to keep old apps running. However, that doesn't necessarily mean that we need to maintain it forever and ever. Its still possible to run old unmaintained versions of fedora (although we don't recommend it). In a similar fashion one could keep an old runtime around for an old app you need to run (not so bad here as it affects only that app). Furthermore, the set of packages where we need to give this guarantee is not the whole distro, but a subset, and in particular a subset which contains zero code that runs with elevated privileges (setuid et al doesn't even work in a xdg-app sandbox).
That said, "stable ABI" is always a grey area. Does fixing an obvious bug break ABI if code relies on the bug? In reality what happens is we do our best to not break any real existing app, and if we accidentally do we fix it in another update. This is trickier in a runtime as we may not necessarily control or be able to test all the users of the runtime, like we do in the fedora repos. In practice, "never change" probably means "be more cautious about updates in a runtime than in a regular distro update".
Yeah, because as you say translations inside Docker have been lower priority, most of the effort so far has been on just ditching them rather than the modularization this needs.
Are there any docs somewhere on how the locale-archive thing works? It seems not a lot of distros are using that.
Let's figure out what's needed and get that into base RPM. I have been pretty clearly told by RH management that there's support for that as long as we have clear requirements and a sensible plan. I think one of the lessons learned from Software Collections is that the macro system used there turned out to be harder than it looks.
I think its just hard to automatically make some existing code relocatable. Some code somewhere could just take the PREFIX define and shove it deep into some static structure. xdg-app conceptually makes things easier, because "/app" is always the same and the same length as "/usr", but its still not something you can automatically replace.
The easiest way to relocate is to rebuild with a different prefix, but even that may not work, as many of our packages are not designed to support a non-/usr prefix. Take the firefox shell wrapper for instance. It has hardcoded: MOZ_LIB_DIR="/usr/lib64" SECONDARY_LIB_DIR="/usr/lib"
It would be a small matter of programming to rewrite this at rpm build time, but it is work that has to be done. Rewriting at install time is harder, especially for strings that are in compiled code.
Then you have things like rpaths, module include paths for different dynamic languages, etc... Its tricky. Maybe the people working on Software Collections can weight in with their experience.
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.
Possibly this could be done automatically with the "/app-relocated" builds? I don't know offhand how popular / useful this would be as global policy.
Some things can be done automatically. For instance its easy to rename the desktop files, the icons and the dbus service files. However, it is a bit trickier to make the app listen to a different dbus name. We're working on a glib patch to make this easier: https://bugzilla.gnome.org/show_bug.cgi?id=743933 But in some cases you may have to change the code slightly.
One thing that is different from docker however, is that we generally want translations/locales in the runtime. But these are pretty large, so we want to handle them in a smart way. xdg-app has a feature that allows splitting a runtime into a base and a set of optional extensions that are mounted in the sandbox only when they are installed. I use this in the gnome runtime to split out each locale. Unfortunately Fedora uses a single large locale-archive file for its locales, so its hard to do that. This needs some research to figure out how to do properly.
Fedora Internationalization team working with Glibc to split locale-archive. This is in plan as a change proposal for F23. Hopefully we will see good progress soon. Cheers, Pravin Satpute
On ons, 2015-05-27 at 18:39 +0530, pravin.d.s@gmail.com wrote:
One thing that is different from docker however, is that we generally want translations/locales in the runtime. But these are pretty large, so we want to handle them in a smart way. xdg-app has a feature that allows splitting a runtime into a base and a set of optional extensions that are mounted in the sandbox only when they are installed. I use this in the gnome runtime to split out each locale. Unfortunately Fedora uses a single large locale-archive file for its locales, so its hard to do that. This needs some research to figure out how to do properly.Fedora Internationalization team working with Glibc to split locale-archive. This is in plan as a change proposal for F23.
Hopefully we will see good progress soon.
This sounds excellent! Thanks!
Is this related to the proposal to build a "desktop" via Project Atomic? That seems to me a much simpler approach.
TBH, my "ideal desktop" would look like a ChromeBook except
1. Project Atomic as the OS, serving up web apps in containers, and 2. Firefox Developer Edition as the browser.
On Wed, May 27, 2015 at 2:50 AM, Alexander Larsson alexl@redhat.com wrote:
I'm working on an application sandboxing system called xdg-app, and the surrounding echo-system. I won't go into details, but there are some links to technical details at the end of the mail[1]. The basic idea is that we have two sources (both ostree trees), one called the runtime (/usr), and one called the app (/app), which get combined in a container-like environment at launch time by xdg-app, with configurable degrees of sandboxing. There is also some interaction with the host system so that installed desktop files show up in the shell and dbus session services from apps work.
xdg-app has two major goals, the first is to allow applications to run in a sandboxed environment with minimal access to the host. The second is to allow third parties to create and distribute applications that run on all distributions (and the sandboxing helps making this less risky). To facilitate and test this I've also created an upstream gnome runtime[2] that gnome applications can chose to use. I'm also working on various Portal APIs[3] that allow sandboxed applications to safely interact with the system.
But, third party applications are a long way off in the future, and so are sandboxed applications (which need not only a fleshed out set of sandbox APIs, but also modifications to individual apps). In the meantime it is still interesting to run bundled applications. For instance in the context of an Atomic-based Fedora Workstation (with readonly /usr), or if you want to run older or newer versions of applications than your distribution is shipping.
It would make a lot of sense to use the existing packages in Fedora for this. And in order to kickstart discussions about this I've created an initial sample of a possible Fedora runtime using rpm-ostree and the Fedora 22 repositories:
https://github.com/alexlarsson/fedora-runtime
Building this produces a repo with the main runtime (org.fedoraproject.Platform) and a sdk runtime (org.fedoraproject.Sdk) which has some additional tools for app creation and debugging. It also builds .Var subruntimes that contain /var with the rpm db for use when building apps. The current package set is mostly based on what is in the gnome one, so don't consider this official in any way.
These runtimes are made to work with xdg-app 0.3.0 which are now in updates-testing for F21 and F22. You also need rpm-ostree from git master for the container support to build the fedra runtime.
In order to test the runtime I've also created a firefox application bundle. Unfortunately it requires some hacks in order to be relocated to /app, and to work as a bundle. However, it works pretty well, running somewhat contained with only access to the Downloads xdg directory and with ~/.mozilla being redirected to the per-app persistant data directory (~/.var/app/org.fedoraproject.firefox). Note however, that I would not consider this properly sandboxed, as it uses X11 for rendering, which is not very secure.
The scripts to build the firefox bundle is here:
https://github.com/alexlarsson/fedora-apps
I've also put up a xdg-app repository so that you can easily test this: (Run these commands as non-root, due to the --user args)
xdg-app add-remote --user --no-gpg-verify fedora http://people.redhat.com/~alexl/repo xdg-app install-runtime --user fedora org.fedoraproject.Platform 22 xdg-app install-app --user fedora org.fedoraproject.firefox xdg-app run org.fedoraproject.firefox
Once installed the desktop file will be exported to the session, so you should also be able to launch it from the shell. In theory this should work on any distro, but I've only tried it on F21.
The question is, would the Fedora project be interested in supplying and maintaining a Fedora runtime like this, which allows us (and others) to create applications using the fedora base. And if we do, exactly what should be considered part of the basic platform.
Defining a platform requires a lot of care. It is a balance between wanting as much as possible in it to share more maintainance and updates and make it easier to write apps and on the other hand trying to keep the basic platfrom small, maintained and of high quality. The ABI requirements for a platform is a bit different than a regular distro. The goal is to allow apps built against a particular platform to run for years to come, so it should only do security and very important bugfix updates, and *never* break ABI. On the other hand, its easy to break ABI in a later version of the runtime, because they are parallel installed. This is somewhat different than our current updates which revs libraries during the distro lifetime as long as it also updates all users of it.
An added complexity is that anything in the runtime that relies on some kind of IPC to the host (say the pulseaudio client libraries, or something that uses a dbus interface on the host) requires the host side of that IPC to remain available and backwards compatible in future versions of the distro, so we should err on exposing a minimal set of IPC.
There is also some changes that may be required in the distro to keep unnecessary dependencies out of the runtime. For instance anything related to hardware or system initialization is completely unnecessary. Luckily much of this is being fixed by similar needs from docker already.
One thing that is different from docker however, is that we generally want translations/locales in the runtime. But these are pretty large, so we want to handle them in a smart way. xdg-app has a feature that allows splitting a runtime into a base and a set of optional extensions that are mounted in the sandbox only when they are installed. I use this in the gnome runtime to split out each locale. Unfortunately Fedora uses a single large locale-archive file for its locales, so its hard to do that. This needs some research to figure out how to do properly.
There are also some custom configuration that a runtime needs. For instance, the build script for the fedora runtime above drops in a new fontconfig file that adds a /app/share/fonts fontdir for app-bundled fonts and configuration to include the host fonts (which xdg-app exposes in /run/host/fonts). This would be nicer if this was just a fontconfig subpackage we could pull in, and I'm sure there are more similar configuration options that would be needed.
Creating applications from fedora packages is a bit more complicated. The primary reason is that they need to be relocated to /app. In the hacky script above I just extract the rpm contents to /app and then rewrite some rpaths and shell scripts. A less hacky approach is to rebuild the rpms with a different rpm %_prefix macro, or to use relocatable rpms. It is not really significantly different from creating rpms to use in software collections though, so we have some experience with this.
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).
There are clearly a lot of details here, but I'll stop here and throw this out as the start of a discussion. I'll gladly reply to any questions people may have.
[1] More information: My devconf talk: https://www.youtube.com/watch?v=t-2a_XYJPEY gnome wiki: https://wiki.gnome.org/Projects/SandboxedApps xdg-app code: https://github.com/alexlarsson/xdg-app
[2] Announcement of gnome runtime: https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-a...
[3] https://wiki.gnome.org/Projects/SandboxedApps/DocumentPortal https://wiki.gnome.org/Projects/SandboxedApps/Sandbox
[4] https://mail.gnome.org/archives/gnome-os-list/2015-February/msg00009.html
--
Alexander Larsson Red Hat, Inc alexl@redhat.com alexander.larsson@gmail.com He's a war-weary Republican vampire hunter on a search for his missing sister. She's a ditzy winged queen of the dead with the power to see death. They fight crime!
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Wed, 2015-05-27 at 18:55 -0700, M. Edward (Ed) Borasky wrote:
Is this related to the proposal to build a "desktop" via Project Atomic? That seems to me a much simpler approach.
It is related insofar as an atomic image will make a good 'host' system on which to run xdg-app bundles.
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)
On Thu, 2015-05-28 at 12:43 -0400, Owen Taylor wrote:
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.
Yeah, i agree, its not like having the fedora version and the upstream version installed in parallel would work well anyway (which is which in the shell?). I think we need to handle this in the same way that we handle two different versions of an upstream gedit installed in parallel (which currently has only one at a time being exported to the system). We probably need to mark somehow that this is a fedora built version though. Maybe we could add a packager field to the metadata.
On Thu, May 28, 2015 at 10:16 PM, Alexander Larsson alexl@redhat.com wrote:
On Thu, 2015-05-28 at 12:43 -0400, Owen Taylor wrote:
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.
Yeah, i agree, its not like having the fedora version and the upstream version installed in parallel would work well anyway (which is which in the shell?). I think we need to handle this in the same way that we handle two different versions of an upstream gedit installed in parallel (which currently has only one at a time being exported to the system). We probably need to mark somehow that this is a fedora built version though. Maybe we could add a packager field to the metadata.
Why would that matter to the user? If gedit 3.16.2 is built by Fedora or Upstream is more or less an implementation detail.
On tor, 2015-05-28 at 22:27 +0200, drago01 wrote:
On Thu, May 28, 2015 at 10:16 PM, Alexander Larsson alexl@redhat.com wrote:
On Thu, 2015-05-28 at 12:43 -0400, Owen Taylor wrote:
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.
Yeah, i agree, its not like having the fedora version and the upstream version installed in parallel would work well anyway (which is which in the shell?). I think we need to handle this in the same way that we handle two different versions of an upstream gedit installed in parallel (which currently has only one at a time being exported to the system). We probably need to mark somehow that this is a fedora built version though. Maybe we could add a packager field to the metadata.
Why would that matter to the user? If gedit 3.16.2 is built by Fedora or Upstream is more or less an implementation detail.
Having some kind of provenance seems like a generally useful thing to have. Not saying we need to shove it in the users face, but we do similar things for rpms (f22 tag in version, Packager and Vendor tags in rpm metadata).
If you find some random org.gnome.gedit app installed on your system it would be nice to know who built it. Especially since we can now run cross-distro apps, which means not (almost) all your apps are from fedora.
On fre, 2015-05-29 at 11:48 +0200, Alexander Larsson wrote:
If you find some random org.gnome.gedit app installed on your system it would be nice to know who built it. Especially since we can now run cross-distro apps, which means not (almost) all your apps are from fedora.
We do know what repo it came from though, maybe that is enough, at least if we make it more visible (say in xdg-app list-apps).
desktop@lists.fedoraproject.org
-
Alexander Larsson -
drago01 -
M. Edward (Ed) Borasky -
Matthew Miller -
Matthias Clasen -
Owen Taylor -
pravin.d.s＠gmail.com