Hi all,
In Fedora 31 I'll be disabling the snap plugin from GNOME Software. It's never been enabled in RHEL and so this change only affects Fedora. It's also not installed by default and so this change should only affect a few people. It's also not really a FutureFeature, it's a RemovalOfFeature but I'm happy to write something for the process and release notes if required.
Recently Canonical decided that they are not going to be installing gnome-software in the next LTS, preferring instead to ship a "Snap Store by Canonical" rather than GNOME Software. The new Snap store will obviously not support Flatpaks (or packages, or even firmware updates for that matter). The developers currently assigned to work on gnome-software have been reassigned to work on Snap Store, and I'm not confident they'll be able to keep both the old and new codebases in the air at the same time.
As you might know, enabling the snap plugin also enables the "Snap Store" which seemingly violates the same rules which prevent us installing Flathub by default (enabling access to nonfree software, and software with patent restrictions). Without the Snap Store the snap support is pretty useless, as snapd is so tied to the snapcraft ecosystem, and because you can't actually run your own instance of the snap store, unlike Flatpak.
The existing snap plugin is not very well tested and I don't want to be the one responsible when it breaks. At the moment enabling the snap plugin causes the general UX of gnome-software to degrade, as all search queries are also routed through snapd rather than being handled in the same process. The design of snapd also means that packages just get updated behind gnome-software's back, and so it's very hard to do anything useful in the UI, or to make things like metered data work correctly. There's also still no sandboxing support years after it was promised, which means on Fedora running a snap is no more secure than "wget -O - URL | bash", again much unlike Flatpak.
I appreciate this is going to be controversial, and that some people want snap support turned back on in GNOME Software. My answer there would be that I'm perfectly happy with someone creating a new gnome-software-snap top-level package (plugins in gnome-software are just runtime loaded .so objects, rather than all compiled together) and then they're responsible for keeping it up to date with any plugin ABI breaks in gnome-software upstream (usually once per GNOME cycle) and for any API or behaviour changes in snapd-glib. Basically, as long as it's not my email that gets pinged by bugzilla when it breaks it's fine. There was some suggestion that upstream we'd remove the snap plugin completely, but I think it will remain until we see if snap support improves or deteriorates further.
Comments welcome, but anyone who insults me or insists I do more work than I'm doing now will be ignored.
Richard.
On Thu, Jul 11, 2019 at 8:22 AM Richard Hughes hughsient@gmail.com wrote:
Hi all,
In Fedora 31 I'll be disabling the snap plugin from GNOME Software. It's never been enabled in RHEL and so this change only affects Fedora. It's also not installed by default and so this change should only affect a few people. It's also not really a FutureFeature, it's a RemovalOfFeature but I'm happy to write something for the process and release notes if required.
Recently Canonical decided that they are not going to be installing gnome-software in the next LTS, preferring instead to ship a "Snap Store by Canonical" rather than GNOME Software. The new Snap store will obviously not support Flatpaks (or packages, or even firmware updates for that matter). The developers currently assigned to work on gnome-software have been reassigned to work on Snap Store, and I'm not confident they'll be able to keep both the old and new codebases in the air at the same time.
This is completely news to me. As far as I knew, Canonical was still actively committed to maintaining the snap plugin upstream and advancing it as a solution for distro integration for snaps in non-Ubuntu distributions.
My understanding of the situation was that Canonical is working on a separate experience tailored for Ubuntu because they have extra needs, but all of it was built on GNOME Software in the first place.
As you might know, enabling the snap plugin also enables the "Snap Store" which seemingly violates the same rules which prevent us installing Flathub by default (enabling access to nonfree software, and software with patent restrictions). Without the Snap Store the snap support is pretty useless, as snapd is so tied to the snapcraft ecosystem, and because you can't actually run your own instance of the snap store, unlike Flatpak.
My opinion on this is that because we don't ship the plugin or snapd by default on any variant of Fedora, we don't really run counter to the rules. If there's something more specific you'd like for the snap integration in Fedora to do, that can be discussed separately and please talk to me off-list about it.
The existing snap plugin is not very well tested and I don't want to be the one responsible when it breaks. At the moment enabling the snap plugin causes the general UX of gnome-software to degrade, as all search queries are also routed through snapd rather than being handled in the same process. The design of snapd also means that packages just get updated behind gnome-software's back, and so it's very hard to do anything useful in the UI, or to make things like metered data work correctly. There's also still no sandboxing support years after it was promised, which means on Fedora running a snap is no more secure than "wget -O - URL | bash", again much unlike Flatpak.
This actually hasn't been true for almost a year (snapd has seccomp and other filters in place), and in the last few months, we've rolled out *very basic* SELinux support into snapd. Today, snaps are sandboxed through the snapd-selinux policy, which generally confines snaps to only interacting with each other, and select holes for system integration.
We've been working very hard upstream on improving this story for Fedora, and we've made tremendous progress.
I appreciate this is going to be controversial, and that some people want snap support turned back on in GNOME Software. My answer there would be that I'm perfectly happy with someone creating a new gnome-software-snap top-level package (plugins in gnome-software are just runtime loaded .so objects, rather than all compiled together) and then they're responsible for keeping it up to date with any plugin ABI breaks in gnome-software upstream (usually once per GNOME cycle) and for any API or behaviour changes in snapd-glib. Basically, as long as it's not my email that gets pinged by bugzilla when it breaks it's fine. There was some suggestion that upstream we'd remove the snap plugin completely, but I think it will remain until we see if snap support improves or deteriorates further.
Would it make sense for Zygmunt and Maciek (CC'd to this email) to be added as CC contacts on Bugzilla, so they can address snap plugin issues when they arise?
Comments welcome, but anyone who insults me or insists I do more work than I'm doing now will be ignored.
I'm just generally confused about this, and somewhat blindsided... I wish someone had looped *me* into these conversations, as one of the snap support maintainers in Fedora, I'm relying on these things to provide a good experience for Fedora users of snaps...
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, 11 Jul 2019 at 14:52, Neal Gompa ngompa13@gmail.com wrote:
My understanding of the situation was that Canonical is working on a separate experience tailored for Ubuntu because they have extra needs, but all of it was built on GNOME Software in the first place.
No, it's also a new codebase: https://github.com/ubuntu/snap-store -- it's confusing as the name "Snap Store" is also the name of the debadged-gnome-software version too.
My opinion on this is that because we don't ship the plugin or snapd by default on any variant of Fedora, we don't really run counter to the rules.
So in the same way, we could have a checkbox for "Flathub support" in the gnome-software addons page? I don't think that would wash with legal as we would be "facilitating" access to patent encumbered software. I don't think the "by default" arguments protects us like that.
Would it make sense for Zygmunt and Maciek (CC'd to this email) to be added as CC contacts on Bugzilla, so they can address snap plugin issues when they arise?
No, as they're not the ones committing fixes to gnome-software. Watching a bugzilla ticket doesn't equate to being responsible for bugs. The snap plugin self tests are failing in CI, and we can't even update to a newer gnome-software in rawhide as the version of snapd-glib is too old. Usually when that happens either me or Kalev have to hunt down the new tarballs, add any new BRs, scratch build, build, submit as an update etc and that's just not fair.
I'm just generally confused about this, and somewhat blindsided...
I was informed of the Canonical decision a few weeks ago, and it too took me by surprise. I guess winning the war comes at a cost, and this camel has a broken back.
I wish someone had looped *me* into these conversations, as one of the snap support maintainers in Fedora, I'm relying on these things to provide a good experience for Fedora users of snaps...
I was asked not to distribute details about the conversations until they had made a public statement, which still hasn't been done. I'm not comfortable with the situation at all either but we have to do something.
Richard.
On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes hughsient@gmail.com wrote:
On Thu, 11 Jul 2019 at 14:52, Neal Gompa ngompa13@gmail.com wrote:
My understanding of the situation was that Canonical is working on a separate experience tailored for Ubuntu because they have extra needs, but all of it was built on GNOME Software in the first place.
No, it's also a new codebase: https://github.com/ubuntu/snap-store -- it's confusing as the name "Snap Store" is also the name of the debadged-gnome-software version too.
My opinion on this is that because we don't ship the plugin or snapd by default on any variant of Fedora, we don't really run counter to the rules.
So in the same way, we could have a checkbox for "Flathub support" in the gnome-software addons page? I don't think that would wash with legal as we would be "facilitating" access to patent encumbered software. I don't think the "by default" arguments protects us like that.
Would it make sense for Zygmunt and Maciek (CC'd to this email) to be added as CC contacts on Bugzilla, so they can address snap plugin issues when they arise?
No, as they're not the ones committing fixes to gnome-software. Watching a bugzilla ticket doesn't equate to being responsible for bugs. The snap plugin self tests are failing in CI, and we can't even update to a newer gnome-software in rawhide as the version of snapd-glib is too old. Usually when that happens either me or Kalev have to hunt down the new tarballs, add any new BRs, scratch build, build, submit as an update etc and that's just not fair.
For what it's worth, Robert Ancell also has an RHBZ account and can be added as a CC if needed. That said, Maciek and Zygmunt are the folks at Canonical generally responsible for ensuring the non-Ubuntu experience is as good as it can be. They are the people I work with for Fedora considerations upstream most of the time. They are both knowledgeable and capable of working on that side if needed.
I was unaware you've been needing new releases of snapd-glib more frequently. I've mainly been updating them whenever I get a bug report or when I notice a new version is available. If you need me to be more aggressive on updating snapd-glib, I could have done that.
I'm just generally confused about this, and somewhat blindsided...
I was informed of the Canonical decision a few weeks ago, and it too took me by surprise. I guess winning the war comes at a cost, and this camel has a broken back.
I wish someone had looped *me* into these conversations, as one of the snap support maintainers in Fedora, I'm relying on these things to provide a good experience for Fedora users of snaps...
I was asked not to distribute details about the conversations until they had made a public statement, which still hasn't been done. I'm not comfortable with the situation at all either but we have to do something.
:(
On Thu, 2019-07-11 at 13:14 -0400, Neal Gompa wrote:
On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes hughsient@gmail.com wrote:
On Thu, 11 Jul 2019 at 14:52, Neal Gompa ngompa13@gmail.com wrote:
My understanding of the situation was that Canonical is working on a separate experience tailored for Ubuntu because they have extra needs, but all of it was built on GNOME Software in the first place.
No, it's also a new codebase: https://github.com/ubuntu/snap-store -- it's confusing as the name "Snap Store" is also the name of the debadged-gnome-software version too.
My opinion on this is that because we don't ship the plugin or snapd by default on any variant of Fedora, we don't really run counter to the rules.
So in the same way, we could have a checkbox for "Flathub support" in the gnome-software addons page? I don't think that would wash with legal as we would be "facilitating" access to patent encumbered software. I don't think the "by default" arguments protects us like that.
Would it make sense for Zygmunt and Maciek (CC'd to this email) to be added as CC contacts on Bugzilla, so they can address snap plugin issues when they arise?
No, as they're not the ones committing fixes to gnome-software. Watching a bugzilla ticket doesn't equate to being responsible for bugs. The snap plugin self tests are failing in CI, and we can't even update to a newer gnome-software in rawhide as the version of snapd-glib is too old. Usually when that happens either me or Kalev have to hunt down the new tarballs, add any new BRs, scratch build, build, submit as an update etc and that's just not fair.
For what it's worth, Robert Ancell also has an RHBZ account and can be added as a CC if needed. That said, Maciek and Zygmunt are the folks at Canonical generally responsible for ensuring the non-Ubuntu experience is as good as it can be. They are the people I work with for Fedora considerations upstream most of the time. They are both knowledgeable and capable of working on that side if needed.
I was unaware you've been needing new releases of snapd-glib more frequently. I've mainly been updating them whenever I get a bug report or when I notice a new version is available. If you need me to be more aggressive on updating snapd-glib, I could have done that.
I'm just generally confused about this, and somewhat blindsided...
I was informed of the Canonical decision a few weeks ago, and it too took me by surprise. I guess winning the war comes at a cost, and this camel has a broken back.
I wish someone had looped *me* into these conversations, as one of the snap support maintainers in Fedora, I'm relying on these things to provide a good experience for Fedora users of snaps...
I was asked not to distribute details about the conversations until they had made a public statement, which still hasn't been done. I'm not comfortable with the situation at all either but we have to do something.
Practically speaking, Neal, can you not just create the 'gnome- software-snap' package Richard suggested, and maintain that? Is there any problem with doing so?
On Thu, Jul 11, 2019 at 2:37 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2019-07-11 at 13:14 -0400, Neal Gompa wrote:
On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes hughsient@gmail.com wrote:
On Thu, 11 Jul 2019 at 14:52, Neal Gompa ngompa13@gmail.com wrote:
My understanding of the situation was that Canonical is working on a separate experience tailored for Ubuntu because they have extra needs, but all of it was built on GNOME Software in the first place.
No, it's also a new codebase: https://github.com/ubuntu/snap-store -- it's confusing as the name "Snap Store" is also the name of the debadged-gnome-software version too.
My opinion on this is that because we don't ship the plugin or snapd by default on any variant of Fedora, we don't really run counter to the rules.
So in the same way, we could have a checkbox for "Flathub support" in the gnome-software addons page? I don't think that would wash with legal as we would be "facilitating" access to patent encumbered software. I don't think the "by default" arguments protects us like that.
Would it make sense for Zygmunt and Maciek (CC'd to this email) to be added as CC contacts on Bugzilla, so they can address snap plugin issues when they arise?
No, as they're not the ones committing fixes to gnome-software. Watching a bugzilla ticket doesn't equate to being responsible for bugs. The snap plugin self tests are failing in CI, and we can't even update to a newer gnome-software in rawhide as the version of snapd-glib is too old. Usually when that happens either me or Kalev have to hunt down the new tarballs, add any new BRs, scratch build, build, submit as an update etc and that's just not fair.
For what it's worth, Robert Ancell also has an RHBZ account and can be added as a CC if needed. That said, Maciek and Zygmunt are the folks at Canonical generally responsible for ensuring the non-Ubuntu experience is as good as it can be. They are the people I work with for Fedora considerations upstream most of the time. They are both knowledgeable and capable of working on that side if needed.
I was unaware you've been needing new releases of snapd-glib more frequently. I've mainly been updating them whenever I get a bug report or when I notice a new version is available. If you need me to be more aggressive on updating snapd-glib, I could have done that.
I'm just generally confused about this, and somewhat blindsided...
I was informed of the Canonical decision a few weeks ago, and it too took me by surprise. I guess winning the war comes at a cost, and this camel has a broken back.
I wish someone had looped *me* into these conversations, as one of the snap support maintainers in Fedora, I'm relying on these things to provide a good experience for Fedora users of snaps...
I was asked not to distribute details about the conversations until they had made a public statement, which still hasn't been done. I'm not comfortable with the situation at all either but we have to do something.
Practically speaking, Neal, can you not just create the 'gnome- software-snap' package Richard suggested, and maintain that? Is there any problem with doing so?
Technically speaking, I can.
However, GNOME Software provides no ABI guarantees for plugins, which is why all of them are in-tree. If an update occurs even within stable releases, I would expect it to have a chance to break. I considered this approach when I introduced snapd to EPEL7, but discarded it for this reason.
If forced to, I'll do that, but I'd really rather avoid having to go down that path. And if GNOME Software removes the plugin, that makes it even harder on me. But again, if forced, I guess I'll do something to try to provide a good experience for Fedora Workstation users. I don't know what I'll do, but I'll try to figure something out.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, 11 Jul 2019 at 21:02, Neal Gompa ngompa13@gmail.com wrote:
If an update occurs even within stable releases, I would expect it to have a chance to break.
We don't break plugin ABI in stable GNOME releases. e.g. 3.32.1 will be the same internal ABI as 3.32.x. In development releases (e.g. 3.33.x) all plugin ABI is fair game.
Also note: at the moment the plan is to keep the snap plugin in the upstream tree unless something drastic changes.
Richard.
Thanks Neal.
Let me reassure you that we are committed to maintaining the G-S Snap plugin and snapd-glib. We do want to ensure it’s available for any user of GNOME Software that wishes to use Snaps, regardless of which distro they are using. The Snap plugin is enabled in all Ubuntu releases so it should work well, but if there are unit test failures please let us know.
We’re happy for the Snap plugin to be built in a separate source package for Fedora if that’s necessary and we’re obviously keen to see snapd-glib up to date in Fedora. The dependencies are fairly light so it should be quick to update but let us know if there is anything we can do to make this easier. Note that snapd-glib updates frequently to enable new features in snapd but retains backwards compatibility.
It’s still very early days for our ideas for https://github.com/ubuntu/snap-store and we’ll post more detailed information in the next few weeks.
On Fri, Jul 12, 2019 at 5:15 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes hughsient@gmail.com wrote:
On Thu, 11 Jul 2019 at 14:52, Neal Gompa ngompa13@gmail.com wrote:
My understanding of the situation was that Canonical is working on a separate experience tailored for Ubuntu because they have extra needs, but all of it was built on GNOME Software in the first place.
No, it's also a new codebase: https://github.com/ubuntu/snap-store -- it's confusing as the name "Snap Store" is also the name of the debadged-gnome-software version too.
My opinion on this is that because we don't ship the plugin or snapd by default on any variant of Fedora, we don't really run counter to the rules.
So in the same way, we could have a checkbox for "Flathub support" in the gnome-software addons page? I don't think that would wash with legal as we would be "facilitating" access to patent encumbered software. I don't think the "by default" arguments protects us like that.
Would it make sense for Zygmunt and Maciek (CC'd to this email) to be added as CC contacts on Bugzilla, so they can address snap plugin issues when they arise?
No, as they're not the ones committing fixes to gnome-software. Watching a bugzilla ticket doesn't equate to being responsible for bugs. The snap plugin self tests are failing in CI, and we can't even update to a newer gnome-software in rawhide as the version of snapd-glib is too old. Usually when that happens either me or Kalev have to hunt down the new tarballs, add any new BRs, scratch build, build, submit as an update etc and that's just not fair.
For what it's worth, Robert Ancell also has an RHBZ account and can be added as a CC if needed. That said, Maciek and Zygmunt are the folks at Canonical generally responsible for ensuring the non-Ubuntu experience is as good as it can be. They are the people I work with for Fedora considerations upstream most of the time. They are both knowledgeable and capable of working on that side if needed.
I was unaware you've been needing new releases of snapd-glib more frequently. I've mainly been updating them whenever I get a bug report or when I notice a new version is available. If you need me to be more aggressive on updating snapd-glib, I could have done that.
I'm just generally confused about this, and somewhat blindsided...
I was informed of the Canonical decision a few weeks ago, and it too took me by surprise. I guess winning the war comes at a cost, and this camel has a broken back.
I wish someone had looped *me* into these conversations, as one of the snap support maintainers in Fedora, I'm relying on these things to provide a good experience for Fedora users of snaps...
I was asked not to distribute details about the conversations until they had made a public statement, which still hasn't been done. I'm not comfortable with the situation at all either but we have to do something.
:(
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, Jul 11, 2019 at 9:13 PM Robert Ancell robert.ancell@canonical.com wrote:
Thanks Neal.
Let me reassure you that we are committed to maintaining the G-S Snap plugin and snapd-glib. We do want to ensure it’s available for any user of GNOME Software that wishes to use Snaps, regardless of which distro they are using. The Snap plugin is enabled in all Ubuntu releases so it should work well, but if there are unit test failures please let us know.
What I'm confused about is how the situation got to this point. Richard seems to indicate that this has been broken in GNOME Software upstream for some time, and that's concerning. I thought you worked upstream in GNOME on this?
We’re happy for the Snap plugin to be built in a separate source package for Fedora if that’s necessary and we’re obviously keen to see snapd-glib up to date in Fedora. The dependencies are fairly light so it should be quick to update but let us know if there is anything we can do to make this easier. Note that snapd-glib updates frequently to enable new features in snapd but retains backwards compatibility.
Honestly, the only reason I hadn't updated it to 1.48 is due to being busy and lack of noticing it's there. It's been generally easy for me to update it across all Fedora releases and even EPEL7.
I've pushed updates to Bodhi now for snapd-glib 1.48, in addition to pushing it into Rawhide: * F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b6612c5fe5 * F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-bc3dfb389f * EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-238f49e9a5
On Thu, Jul 11, 2019 at 5:34 PM Richard Hughes hughsient@gmail.com wrote:
On Thu, 11 Jul 2019 at 21:02, Neal Gompa ngompa13@gmail.com wrote:
If an update occurs even within stable releases, I would expect it to have a chance to break.
We don't break plugin ABI in stable GNOME releases. e.g. 3.32.1 will be the same internal ABI as 3.32.x. In development releases (e.g. 3.33.x) all plugin ABI is fair game.
Also note: at the moment the plan is to keep the snap plugin in the upstream tree unless something drastic changes.
I'd *really* prefer to find a solution which lets us keep building the plugin as part of the gnome-software source package. If there have been snap plugin specific issues, I haven't heard of them, and I *know* that Robert and the rest of the folks working on non-Ubuntu snap work would like to know about them, so they can do something about it. Sadly, omniscience and mind reading technology don't exist, so we need to be told these things. :)
-- 真実はいつも一つ！/ Always, there's only one truth!
Ideally, this would be submitted as a Change proposal, but I don't think it really matters. I would ask you to file an issue for the Release Notes[1] so it can be communicated to the public (unless someone else steps forward and maintains it so you don't have to).
[1] https://pagure.io/fedora-docs/release-notes/new_issue
-
Adam Williamson -
Ben Cotton -
Neal Gompa -
Richard Hughes -
Robert Ancell