Discover Backends
Open, Needs TriagePublic

Description

What are everyone's (within Kubuntu if this wasn't obvious 😉) thoughts about adding all available and usable Discover backends as options for people when using Discover? Currently upstream there's Snap and Flatpak backends, and also seemingly a few more, but we only have the Flatpak one packaged.

We could offer the Snap backend, but 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).

Thoughts?

tsimonq2 created this task.Dec 11 2017, 5:20 AM
ngraham added a subscriber: apol.
tsimonq2 updated the task description. (Show Details)Dec 11 2017, 5:31 AM

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.

tsimonq2 updated the task description. (Show Details)Dec 11 2017, 5:36 AM

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....

apol added a comment.Dec 11 2017, 3:04 PM

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!

ngraham added a comment.EditedDec 11 2017, 3:19 PM

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?

apol added a comment.Dec 11 2017, 5:24 PM

@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.

ngraham added a comment.EditedDec 11 2017, 5:30 PM

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?

apol added a comment.Dec 11 2017, 5:51 PM

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.