http://www.ubuntu.com/legal/contributors 2016-07-23 2:46 GMT+02:00 Neal Gompa <ngompa13@xxxxxxxxx>: > Hello all, > > Over the course of this week, I've been involved in the first Snap > sprint focused on making the Snap system broadly useful and workable > across a wide variety of Linux distributions. While I obviously did > not represent Fedora in any official capacity (and I'm not even really > sure it's possible for a person to represent such a diverse community > such as ours), I ensured that Fedora was part of the conversation when > it came to evolving the Snap system. > Thanks Neal for sharing your notes. It's interesting to have accurate status of snappy on Fedora. > There are some interesting highlights from the event that I think are > quite relevant to Fedora: > > * Snaps are intended to evolve beyond Ubuntu. While snaps have their > origins in Click for Ubuntu Touch user apps, the Snap system is > clearly designed to support a broader array of capabilities and > systems. Snaps can be used to handle OS components, services, CLI > tools, desktop applications, build environments, web services, and so > on. > Well, I know first hand, that non-Ubuntu system support is still alpha at best. It's welcome that Canonical is working to expand support to other distributions, windowing system, and kernel security modules, though. > * Runtimes are supported in snaps. While technically there's no > specific "type" of snap, it's possible to build a snap that contains > common libraries and services that can be connected to other snaps. > This is done through the "plugs" and "slots" that can be used to > create interfaces among them. This is a true superset of the > capability provided by Flatpak through Portals, since it can be used > to export non-DBus oriented communications mechanisms. This is > described on the Snapcraft documentation[0]. > I wouldn't be so affirmative on that, it slightly inaccurante but I'll let people with more knowledge of flatpak internals answering that. > * SELinux-based confinement is a _very_ high priority. As most know, > snapd currently only works on systems using AppArmor and seccomp, and > only those using AppArmor patches developed by Ubuntu that are in the > process of being upstreamed. For SELinux support, we aren't exactly > sure how this will be pulled off. I proposed something along the lines > of how confinement works for Docker containers and virtual machines > (sVirt), but I'm not sure if that's the right approach for enabling > proper confinement while allowing the sandboxes to support the > interconnection capabilities of snaps. The way that the Snap system > enforces confinement using AppArmor and seccomp is by generating a > profile for the snap on the fly that defines what it can and cannot do > and access for the mounted snap filesystem (from the squashfs image). > This policy is applied, locking down the snap's environment. I'm > curious to hear from others on how the approach should be for > providing confinement using SELinux. > To be more precise, until recently, snappy website recommended to setenforce 0 as it didn't interact well with SELinux. That statement was removed though it's still not fixed. > * Detection and auto-configuration of confinement is coming. > Snap-confine currently relies on build time configuration to figure > out whether it should support confinement. However, this will change. > Snap-confine will be merged into snapd and snapd will be set up to > query and set up whatever confinement is possible, given the > information returned from the kernel and systemd about what > confinement mechanisms are supported. > > * The snap format is simple and lends itself to being able to be > generated by many kinds of tools. While the current main tool used to > make snaps is Snapcraft, there's no reason someone couldn't build a > "snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could > theoretically use RPM spec format (or a derivative of it) to build > snaps. > > * Snapcraft is currently Ubuntu specific, but will be reworked to > remove that. Snapcraft and the snapcraft.yaml format will change to > enable easily and reproducibly building snaps using Debian and RPM > based distro bases in addition to Ubuntu[3]. The goal is to make it > possible for a distribution like Fedora to be able to easily add > support for building snaps and snap parts from Fedora infrastructure > using Fedora packages/software, along the lines of what we do now for > Docker images, so that people can use them in their own snaps or > solutions. > > * The VideoLAN project now officially offers a VLC snap[4], and the > Elementary OS folks are working on snaps for their Pantheon Desktop > applications and tying it to an Elementary GTK runtime snap. > Similarly, the KDE Neon folks are developing a KDE Frameworks 5 > runtime snap and building application snaps to use them. > > * Using snapd with alternative stores is possible. In fact, the tests > done on snapd builds rely on a "fake store" set up locally to be able > to test all the functionality. The store API is fully documented[5] > and there's even a simple implementation of it[6]. > In practice, distributing snap packages requires relying on Canonical's proprietary store, as the client is tied to that API. Yes, one can implement its own store, but no guarantee that the API won't change in the future, nor that Canonical will accept to let the community participate in defining that API if they want to. > * Support for snaps to offer AppStream metadata is coming. The Snappy > development team is highly interested in implementing support for > AppStream so that it's easier for software centers and other tools to > be able to discover and interact with snaps through snapd. Snapd > support for AppStream XML through its API[7] for software centers is > planned as well. > > * Fedora packaging of the snap system is under active development. > Zygmunt Krynicki (zyga) is extremely enthused to get the system in > Fedora fully functional, and I'm mentoring him on various aspects of > Fedora packaging, including maintenance and policies. > Great, thanks to Zygmunt! > * Snap development is rather fast, with releases expected to occur > every two weeks. There's no intention to break the API between snapd > and the rest of the system, so interaction points should be fine. The > pace is well-suited for being able to push updates to Fedora in a > timely fashion so that users can get the best experience possible for > using applications and services under the system. > No intention to change interfaces, but still happened recently. > I know that the Workstation WG is very much behind Flatpak right now, > but I see no reason that we cannot offer both. In fact, it is in the > best interests of our users to fully enable both systems to the best > extent we can, so that they have the freedom to develop and use > applications as they see fit. > There are two things here: first, providing snappy in our repositories, second, making it our preferred next-gen packaging format for desktop app. AFAIK, as long as Fedora Packaging guidelines are respected, there's nothing preventing the former, it's even encouraged if there are volunteers to maintain it in Fedora. On the other hand, the latter is unlikely to happen unlike some company ill-advised marketing press releases said w/o ever consulting us. Again, I'm speaking in my own name, but there are significant flaws that are not in favour of choosing snappy as next-gen packaging format. 0. flatpak is currently slightly more mature than snappy. 1. contributing to snap requires signing Canonical CLA, that has proven in the past a powerful repellant to community-based contribution. http://www.ubuntu.com/legal/contributors 2. snappy is still essentially a single-vendor project while flatpak has been developped within the GNOME community by people from various companies (Red Hat, Collabora, Mozilla, Endless, CodeThink just to list top contributors). 3. distributing snappy apps still relies on Canonical proprietary store. Without strong commitment in that read, this will hinder adoption by other distros. You can argue that 1 and 2 are non-technical points, but there are still very relevant within an open source community context. 3. is critical aspect for adoption. In the end, Fedora contributors will choose whatever projects they feel like to integrate in Fedora, flatpak, snappy or something completely different. > So, what does everyone think of Snappy, given this new information? > Constructive feedback is highly valuable and very welcome, especially > at this early stage! > > Best regards, > Neal > As a reminder, Neal is no affiliated to Canonical, and I'm grateful that he accepted to share his vision about snappy. So please, keep the discussion civilized. Regards, H. > [0]: http://snapcraft.io/docs/reference/interfaces > [1]: https://github.com/ascherer/debbuild > [2]: http://pkgbuild.sourceforge.net/ > [3]: https://bugs.launchpad.net/snapcraft/+bug/1602258 > [4]: https://uappexplorer.com/app/vlc.videolan > [5]: http://search.apps.ubuntu.com/docs/ > [6]: https://github.com/noise/snapstore > [7]: https://github.com/snapcore/snapd/blob/master/docs/rest.md > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
