Personally my vote goes to Flatpak. It seems like it has better momentum at this point, and there's the added bonus that its backend is already packaged and available in Kubuntu.

Well, it would be nice to see snaps offered for those who want them. Are the KDE store offerings available through Discover?

The snap backend is or was a proof of concept bit of code, and is still deliberately set to a default of OFF in cmake for building.

When I talked to Aleix Pol a while back, he strongly advised against enabling and shipping it for a production distro such as Kubuntu. It won't work properly until the snap store makes some required changes, which as far as I know have still not been done.

So a -1 from me.

I think we should either have one backend or no backends installed automatically by default (so that we don't give the impression that we're endorsing one or the other).

Nor do I agree with that assessment.

Aleix is going to talk with snapcraft -devs, but sounds like we may be able to enable the snap backend when we do Plasma 5.12

So lets wait and see....

Hi everyone, really excited to see attention to the subject!

Regarding Discover's snap backend state: it's stable and maintained by me. It should be possible to list and install any snap in the snap store. (if it's not working well, it's a bug, poke me to fix it). There's a caveat, though. Snap still doesn't give us appstream ids, so if you search "libreoffice" you will get always packagekit/flatpak + snap, because Discover can't know they are the same. This is the biggest impact of this shortcoming, there are some others, less important. I'm working with snap/snapcraft to make it ready and available soon, but it's still not there: https://github.com/snapcore/snapcraft/issues/1694

Regarding the overall vision, I suggest offering both snap and flatpak runtimes with the distribution. I don't think we want users worrying about which applications they are using and if they can, or not, or if they should be adding this and that backend. It's confusing enough.

As a distribution you get to choose as well which applications backend to prefer. My suggestion is to leave PacakgeKit (i.e. apt for Kubuntu) as default for one release while having you guys running your favorite bundling system as default and when you consider it's mature enough you do the switch. If I'm not mistaken, your next release is an LTS, so it's a good opportunity to have all backends available (users will eventually want an up to date LibreOffice).

Hope this helps, please poke if there's questions or suggestions!

In the absence of a packaged Snap backend, I've been trying out the Flatpak backend with Flathub on Kubuntu and I ran into the same problem that @apol mentioned: duplicate entries (https://bugs.kde.org/show_bug.cgi?id=387790). The issue seems to be that the appstream IDs differ between the Flathub versions and the distro-packaged versions; e.g. Flathub Blender is org.blender.Blender.desktop, while Kubuntu's blender package is blender.desktop. Since the appstream IDs differ, Discover considers them to be different apps and shows duplicate entries, leading to a confusing user experience:

I can start filing bugs on individual packages, but this is gonna be a big task and I thought I'd bring it up here first to discuss how to tackle the problem. Who's right? Which appstream ID is correct?

@ngraham No, you didn't run into the same issue. Flatpak does provide an appstream id, that doesn't mean it's the right one though ;) This is something to bring to blender devs, not kubuntu.

The root causes are different, but the issue of duplicate apps is the same, from a user perspective.

What is the canonical source of truth regarding the appstream ID? After installing the Flatpak backend alongside the existing PackageKit backend, every app with a Flatpak version that I looked at had a appstream ID that differed between the two backends. Who's right? How can we unify these?

I think you use Arch, right? Does the Arch packaging for apps also available on Flathub use the same appstream ID?

In T7566#120438, @ngraham wrote:

The root causes are different, but the issue of duplicate apps is the same, from a user perspective.

What is the canonical source of truth regarding the appstream ID? After installing the Flatpak backend alongside the existing PackageKit backend, every app with a Flatpak version that I looked at had a appstream ID that differed between the two backends. Who's right? How can we unify these?

I think you use Arch, right? Does the Arch packaging for apps also available on Flathub use the same appstream ID?

Off-topic on this thread, really. Let's continue the discussion on bug 387790 as it's not as short of an answer as we'd like...

Anyway, I've been using the Flatpak backend in Kubuntu and there are some bugs that would make me not want to ship it or make it the default backend without more testing, bugfixing, and polishing. It's really promising though, and I encourage folks to try it out.

FWIW, we've battered the Flatpak backend into really good shape for Discover 5.12. I would be in favor of including it along with the PackageKit backend. It should not be made the default backend yet, though.

I just wanted to chime in with my +1 for installing/enabling the back-ends by default when you are satisfied with stability. It would really help new users, (and experienced users) with finding the latest versions of applications.

My feeling is that we might look at enabling backends by default for an LTS point release? If integration issues receive some fixes and updates to that LTS for them.

@valorie Should this be named 18.04 point release based on @rikmills suggestion?

@acrouthamel good point; done.

According to Martin Wimpress, Neon will be shipping the snap backend by default. And the KDE snap wiki page is 'out of date' and only real issue is that duplication due to that lack of appstream data.

So shall we reconsider?

Discover 5.12 is not capable of installing snaps that need 'classic confinement" like Skype. That comes in discover 5.13.

I'm surprised Neon is using snap due to the appstream issue. It also has problems with respecting themes (or the lack thereof). Having used both for a variety of popular desktop apps, I would rather see Flatpak enabled as a backend than Snap.

So shall we reconsider?

-1 if there's issues with some types of snaps (classic) and appstream issues.

[spam comment removed by sysadmin]

BTW Neon is shipping with the Snap and Flatpak backends (+Flathub) installed by default and it's worked out very well for them. Kubuntu might want to consider doing the same thing.

They wouldn't even need to enable the Flathub repo like Neon did. Just having the backend installed by default would improve the out of box experience enormously. (You could then just go to flathub.org and click-to-install, no restart needed)

But I guess this won't happen, because Canonical prefers to push their own solution.

I think having all of the backends turned on would make sense. Choice is a good thing to have. Without that, it would be something analogous to having Okular without anything besides PDF support.

Now if functionality is a problem, I can respect that, but if everything works good, turn them all on. The dupes are no big deal as ⓐ the software attempts to put dupes together where metadata allows and ⓑ the source of each item is displayed so one can make out the difference between them.

Canonical can't force anyone to do anything in relation to Discover backends. Regardless of how they feel about Snaps, I don't think anyone would take well an edict from on high that we can only use Snaps. In Lubuntu, as with all other flavors, we are forced to have snapd because it's part of the core seed but we don't install any Snaps by default (not even the so-called core Snap) so snapd isn't even running by default. tl;dr this has nothing to do with Canonical.