Fedora, GNOME Software, and snap
LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing |
A question about the future of package distribution is at the heart of a disagreement about the snap plugin for the GNOME Software application in Fedora. In a Fedora devel mailing list thread, Richard Hughes raised multiple issues about the plugin and the direction that he sees Canonical taking with snaps for Ubuntu. He plans to remove support for the plugin for GNOME Software in Fedora 31.
There are currently two major players for cross-distribution application bundles these days: snaps, which were developed by Canonical for Ubuntu and the Snap Store, and Flatpak, which was developed by Alexander Larsson of Red Hat as part of freedesktop.org. Both systems are available for multiple Linux distributions. They are meant to give an "app-like" experience, where users simply install an application, which comes with any dependencies it has that are not provided by the snap or Flatpak runtime.
The GNOME Software application has a snap plugin that, when enabled, supports the distribution, installation, and management of snaps. The Fedora project currently provides the snap plugin as a package in Fedora 30, though it is not installed by default. Hughes is the Fedora maintainer for the plugin; he announced his intention to disable the plugin since, he says, he was told that Canonical was not going to be installing GNOME Software in the next Ubuntu Long Term Support (LTS) release.
Hughes is also concerned about the stability of the snap plugin, noting that
"the existing snap plugin is not very well tested and I don't want
to be the one responsible when it breaks
". Additionally, Hughes
outlined a
few other areas of concern that have led him to plan to drop support
for the snap plugin in Fedora.
The other issue that Hughes raised is that in his view, enabling the snap plugin would also enable the Snap Store, which would be a violation of Fedora rules for enabling access to non-free software (the same is true of enabling Flathub support, he said). He noted that he expects that the decision will be controversial and that there will be those that want it turned back on in GNOME Software. He suggested a path forward if there were developers interested in maintaining snap support for GNOME Software:
In a blog post, Hughes provided his views on the situation and the bigger picture. The post was of the form of an extended automotive analogy that took issue with companies that are not working toward enabling an open ecosystem supported and used by multiple parties. Overall, it was a thinly veiled swipe at Canonical.
Among those that disagreed with the decision was Fedora contributor Neal Gompa who disputed many of Hughes's assertions, including the claim that snaps are not sandboxed.
We've been working very hard upstream on improving this story for Fedora, and we've made tremendous progress.
Canonical responds
At the core of the issue of whether Fedora will or won't ship the snap plugin is whether or not Ubuntu will be moving away from GNOME Software and just use its own Snap Store by default for the next Ubuntu LTS release. It's a question that Canonical has not definitively answered, though it has stated that it plans to keep supporting the snap plugin for GNOME Software.
LWN contacted Canonical to ask about Hughes's claims. In an email, Will Cooke, desktop engineering director at Canonical, said that in the last week there have been several discussions at the company about the Snap Store. "To date, there has been no decision on this potential change, nor have any announcements been made to this effect," he said. "We remain committed to maintaining snap support in GNOME Software and ensuring users who wish to use snaps can do so regardless of their Linux distribution."
In the mailing list thread, Canonical developer Robert Ancell
emphasized that Canonical is committed to maintaining the GNOME Software
snap plugin. He also extended an offer of support to help Fedora
include the snap-plugin in a way that is stable. "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
", Ancell wrote. "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.
"
Gompa responded, wondering how the situation had deteriorated to the point where the plugin was seen by Hughes as being unstable. Rather than building a Fedora-specific source package, Gompa would prefer everything to be done upstream, and is hopeful for more communication to help identify any issues.
Flatpak vs. snap
Red Hat is a big supporter of Flatpak. The Fedora Silverblue distribution is designed with Flatpak as a core component, for example. In an interview with LWN, Fedora Project Leader Matthew Miller said that, in his view, Flatpak and snap can both happily coexist. "Obviously Red Hat's desktop team is heavily invested in Flatpak, and we also have members of the Fedora community who are very interested in snaps — and I include Canonical employees working on snap in that," he said.
Of concern to Miller is the source of snaps and in making sure that there are multiple developers and organizations that are producing snaps that are available via GNOME Software. Miller noted that the Fedora project is not just a producer of a base operating system, or just a desktop without apps, it also has a long history of contributors working on packaging end-user applications. "We have a project where Flatpaks in Fedora are actually automatically generated from our existing packages, and some Fedora developers are working on a plan for doing a similar thing with Snaps," Miller said. "We have a talk on that at our upcoming Flock conference and I'm looking forward to learning more."
Decision time
From a governance perspective, Miller explained that Fedora has a defined change process and it's ideally used for anything with a large impact. In Hughes's view, the snap plugin change would only have limited impact. Hughes said that the snap plugin was never shipped for Red Hat Enterprise Linux (RHEL) and it's not a feature that is installed by default for Fedora. The change would only impact a small number of people, he said, so it may not need a full-on change proposal. Fedora program manager Ben Cotton said that while a change proposal would be nice, it probably isn't needed; adding something to the Fedora 31 release notes should do.
Decisions on minor changes can be handled by Fedora maintainers. Miller noted that if Hughes feels like he can't reasonably maintain a feature, that's a judgement call. "Ultimately we do put a lot of trust in our maintainers, and I personally have a lot of trust for Richard here," Miller said. But Miller noted that currently it sounds like there is community interest in preserving the snap plugin and he thinks it's likely that someone will step up to do that. "This is still a developing conversation," he said.
From a user perspective, however, even if Fedora 31 disabled the snap plugin in GNOME Software, users could still download GNOME Software directly from upstream, which still has the plugin."Either the functionality will have a strong owner and support, in which case there will be no problem in Fedora, or else it'll become clear that it's not maintained in which case it will be dropped upstream as well," Miller explained.
The discussion is likely to continue for a while
longer as different developers and community members make their voices
heard on the topic. Fedora 31 is currently scheduled
for release in October, with a beta freeze set for August, so there is
still plenty of time for a final decision to be made.
Index entries for this article | |
---|---|
GuestArticles | Kerner, Sean |
(Log in to post comments)
Fedora, GNOME Software, and snap
Posted Jul 17, 2019 21:13 UTC (Wed) by halla (subscriber, #14185) [Link]
No. There are three. What the author might have meant is "there are two corporate-backed players..." -- which to some minds translates to "important", but for me, as the maintainer of a widely used application, snap is okay but not actively awesome, flatpak sucks because of the attitude of its maintainers towards freedesktop.org standards, and appimage is what works best for my users.
Fedora, GNOME Software, and snap
Posted Jul 17, 2019 21:29 UTC (Wed) by SMK (guest, #131799) [Link]
Fedora, GNOME Software, and snap
Posted Jul 17, 2019 21:48 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
What standards?
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 5:18 UTC (Thu) by davidstrauss (guest, #85867) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 6:39 UTC (Thu) by halla (subscriber, #14185) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 10:11 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 11:17 UTC (Thu) by DigitalBrains (subscriber, #60188) [Link]
The claim made in that PR isPutting larger icons there is not going to make desktops pick them up, if they follow the icon theme spec.The icon theme spec says that the icon theme description file lists all the subdirectories of the theme. "For every subdirectory there must be a section in the index.theme file describing that directory". If you now take the latest version of hi-color's index.theme, this does not list a directory for 1024×1024 icons. Even the scalables top out at MaxSize=512 or smaller. So the claim seems substantiated: if an implementation follows the icon theme spec by taking index.theme as the leading source of available directories, they will not notice a 1024x1024 directory. In fact, even creating that directory violates the spec as it says that "for every subdirectory there must be a section in the index.theme file describing that directory".
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 11:36 UTC (Thu) by halla (subscriber, #14185) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 11:44 UTC (Thu) by rsidd (subscriber, #2582) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 11:58 UTC (Thu) by halla (subscriber, #14185) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 14:47 UTC (Thu) by zdzichu (subscriber, #17118) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 19:55 UTC (Thu) by halla (subscriber, #14185) [Link]
But anyway, anything that forces me, unnecessarily and uselessly, to make a change, a difference per OS is lumber, and in this case, something we had been installing for more than a decade on Linux suddenly was, without any good reason, rejected. I did not like that, and I did not like not getting an answer to my question, and I did not like having to spend time on that bug report.
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 11:53 UTC (Thu) by DigitalBrains (subscriber, #60188) [Link]
I'm trying to understand. Are you saying that the claim from the PRThe biggest icon size supported by the hicolor theme definition is 512x512. Putting larger icons there is not going to make desktops pick them up, if they follow the icon theme spec.might be correct but is irrelevant? Because I think I showed it is correct. You're saying that you want to build large icons for themes that do support it or for people modifying the hicolor theme to include these larger icons?
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 19:57 UTC (Thu) by halla (subscriber, #14185) [Link]
Fedora, GNOME Software, and snap
Posted Jul 20, 2019 0:17 UTC (Sat) by flussence (subscriber, #85566) [Link]
There are four. These three irrelevant perpetually-infighting ones, and the app store everyone uses: Steam, which is a trash fire with no sandboxing.
Fedora, GNOME Software, and snap
Posted Jul 20, 2019 11:49 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
Feel free to provide the evidence that backs this claim. Clearly, not everyone uses steam but can you show that the atleast the majority does?
Fedora, GNOME Software, and snap
Posted Jul 20, 2019 21:37 UTC (Sat) by flussence (subscriber, #85566) [Link]
Fedora, GNOME Software, and snap
Posted Jul 21, 2019 10:29 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
What does showing basic evidence of your claims have to do with any supposed war?
Fedora, GNOME Software, and snap
Posted Jul 21, 2019 20:44 UTC (Sun) by flussence (subscriber, #85566) [Link]
Instead of racing to become the first distro to reinvent 0install packages 2 decades late, take note of what people are actually using computers for, and why that idea was ignored back then.
You refuse to see the wood for the trees.
Fedora, GNOME Software, and snap
Posted Jul 21, 2019 22:17 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Fedora, GNOME Software, and snap
Posted Jul 21, 2019 17:56 UTC (Sun) by ThinkRob (guest, #64513) [Link]
Ignoring, for a moment, the various debates about FOSS v. proprietary, it doesn't seem like Steam's really trying to solve the same thing as snap et al. And it *does* seem to work for what it's trying to do -- letting people sell to Linux users... doesn't it? (Pardon my ignorance of its success/failure -- I don't use it, and never have/will... but it seems like it's popular!)
Fedora, GNOME Software, and snap
Posted Jul 21, 2019 20:28 UTC (Sun) by pizza (subscriber, #46) [Link]
Fedora, GNOME Software, and snap
Posted Jul 22, 2019 22:31 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]
Specifically, it's trying to solve the "I want to sell my proprietary software to Linux users without going insane re: distribution + packaging" problem.
But if you ignore the "sell proprietary software" part, it still has to deal with the "without going insane re: distribution + packaging" part of the problem. The basic point is a reasonable one: Steam seems to have come up with a reasonable solution that allows game makers to solve the main problem snap and flatpack are trying to solve.
Fedora, GNOME Software, and snap
Posted Jul 22, 2019 22:48 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Sure but Steam is not a general purpose solution to the problem. Non-games are not widely using it as a distribution platform. There is no smaller runtimes, no sandboxing, no portals, no confinement etc that makes it useful for that reason
Fedora, GNOME Software, and snap
Posted Jul 24, 2019 20:34 UTC (Wed) by ThinkRob (guest, #64513) [Link]
That said, I can't see why Steam couldn't adopt snap or whatever once they mature somewhat. Or does Steam target systems too old for container tech?
Fedora, GNOME Software, and snap
Posted Jul 24, 2019 20:56 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Right now, the official snap store is proprietary and there is no community store that is not tied to Canonical. Snaps are also not as mature outside of Ubuntu. In theory, all of this is fixable and either snap or flatpak could be adopted by Steam
Fedora, GNOME Software, and snap
Posted Aug 15, 2019 17:16 UTC (Thu) by oak (guest, #2786) [Link]
I.e. It’s not a good candidate for containers, as drivers need to come from the distro.
Another problem is when 3D driver has incompatible C++ dependency compared to what game otherwise depends on...
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 5:01 UTC (Thu) by abo (subscriber, #77288) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 10:00 UTC (Thu) by swilmet (subscriber, #98424) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 6:05 UTC (Thu) by davidstrauss (guest, #85867) [Link]
I disagree that seccomp filtering qualifies as sandboxing, at least for desktop applications. Filters like seccomp are mostly useful for preventing unprivileged code execution from achieving full privilege escalation, as it allows filtering out uncommon and unused system calls that might be useful to an attacker exploiting a kernel vulnerability. It is not terribly useful for sandboxing for desktop applications because escalation to root isn't the prize. The prize is the content in your home directory and other data accessible by your unprivileged (but local) user: SSH keys, other private keys, and PII. It is not sandboxing when the payload for attackers is also in the (supposed) sandbox.
Not only is seccomp filtering weak against the threat model for desktop applications, it also represents no progress toward meaningful sandboxing that *does* require application changes, like replacing traditional expectations around arbitrary $HOME and webcam access with more restrictive mechanisms. Most seccomp filter lists (of the sort used in Snaps, Docker, etc.) are designed to be only as tight as they can be without making anyone change anything. "Sandbox" typically implies something small and well-contained, but this sandbox is constructed by dumping sand anywhere people happen to be going already or might be expected to go.
As for using Snap for server applications, I don't see much value over existing container or virtualization technologies. Many of them have more meaningful and mature sandboxing and developer ecosystems than Snap's.
Fedora, GNOME Software, and snap
Posted Jul 19, 2019 3:54 UTC (Fri) by gdt (subscriber, #6284) [Link]
For the ordinary user the ability of an application to encrypt their ~/Pictures directory is devastating. Flatpak, Snap, AppImage, etc are an opportunity to add more meaningful access control to applications. It's a shame that this opportunity wasn't taken.
Fedora, GNOME Software, and snap
Posted Jul 19, 2019 5:11 UTC (Fri) by abo (subscriber, #77288) [Link]
Fedora, GNOME Software, and snap
Posted Jul 18, 2019 14:04 UTC (Thu) by Freeaqingme (guest, #103259) [Link]
I'm fairly certain Debian will stick to the .deb packaging for the next 100+ years, so when my ryzen 3000 system arrives this weekend I'll just see how Debian performs on a desktop. So long - from an Ubuntu user of 14 years.
Fedora, GNOME Software, and snap
Posted Jul 20, 2019 12:10 UTC (Sat) by mpr22 (subscriber, #60784) [Link]