Snap support?

Desktop Snap Store
1

I posted this on the Snapcraft Forum, regarding my concern about how to get support with Snaps:

It’s not a particularly new concept. There are a few posts on the Snapcraft Forum on the subject and there are even some here.

Anyways, the response I got was less than encouraging for two reasons:

  1. Despite being a concern that applies to countless standard Snaps, there was virtually no response. There certainly was no response from anyone at Canonical or on the Desktop Team.
  2. This quote from the major response I got:

    it’s almost like Canonical have given up and don’t care about this anymore

As I said there, I’m inclined to believe that was a bit of hyperbole, but it concerns me nonetheless.

It especially concerns me as the response suggests that the Snapcraft Forum isn’t really a good place to expect a response from anyone in a position to do anything about the issues at hand.

Thus, I bring the issue here.

Can we please do something to ensure that there are clearly defined support paths for Snaps? If not, I think maybe we should just not have them at all.

16 Likes
2

Thank you for opening the topic. I am a fan of snaps and Snap technology, but I am also worried about the future of Snap.

Technically I see the snap format superior to flatpak in most aspects. With snaps you can do everything, while flatpaks are limited in their usecases.

But I see that many desktop snaps in particular are in terrible condition and are hardly maintained. Even Snaps recommended on the start page. GNOME Calendar is on 44.1 (current version is 46.1), Gnome Boxes is on 45.0 (currently 46.1). Many Gnome Snaps have theming issues, even with the default Yaru theme, while theming for the corresponding flatpak works perfectly. Also many screenshots and app icons are 10 years old, and AppStream data is incorrect. The Josm snap uses a very old Java version and there is no sign of a change. Some Snaps like Gnome Drawing are even not starting, and nobody seems to care.

I don’t blame the corresponding snap maintainers. They are doing a great job and I think Canonical keeps them busy with enough other tasks.

The problem is simply that Canonical needs to hire more people to take care of Snaps maintenance or they just open snap for everyone. Otherwise, unfortunately, I no longer see a future for the format. I would like to use more Snaps, but the Snaps are so poorly maintained in all aspects that they are behind the DEBs and Flatpaks in terms of quality.

This topic also affects Ubuntu as it directly and strongly affects the quality of Ubuntu, so I think the topic is in the right place here.

14 Likes
3

I guess Flatpak/Flathub benefits a lot from allowing drive-by improvements on GitHub. Someone who wants to fix an issue can submit a PR and the maintainer can just merge it without any effort if it looks good and simple. And it’s all public and transparent…

8 Likes
4

I think one of the biggest problems with Snaps is that anyone can make one and have it published on the store. To the end user, especially one familiar with the packages in the Ubuntu archive, this implies a well maintained and well supported piece of software. In reality, this is not the case.

No Snap goes through the rigorous process packages in the archive go through. Concerns about malware there are all but unfounded (even the xz fiasco failed to have any impact on production packages) and, at least with the latest version of Ubuntu, one can always expect the latest software (at least given potential delays due to cycle times). Important metadata is practically required by the packaging guidelines, to boot. Most importantly, there are very clear paths to get support and a virtual guarantee of getting it, even as people come and go.

There’s a lot of one off Snaps by one off publishers that have simply disappeared for whatever reason. To confront this and keep Snaps from coming abandonware, there really needs to be some sort of a solution. Maybe some sort of minimum gap between upstream version?

What’s worse, though, is when I see what amounts to abandonware and it’s not from some fly by night publisher. In the case of GNOME Drawing (which apparently is a literal non-starter), this one done Ken VanDine, who not only hasn’t come and gone, but who actually works for Canonical.

If Canonical themselves cannot maintain their own Snaps, how can we expect a lone publisher to? And if we can’t expect either, why are we even bothering with Snaps at all?

I’ll be honest: I don’t totally love Snaps. However, as Canonical has made it a platform expectation for Ubuntu and all of its flavors to support them, I have tried very hard to do exactly that. I don’t try to convince people to ditch the Firefox Snap in lieu of alternative sources (even though I field a fair amount of requests that way). I’ve even gone so far as to encourage people to use Snaps and defended their merit.

I guess my point is I’m bringing this all up because I want to see a solution to the problem. However, the deeper I get, the more problems I see and the less hopeful I am that this can be solved.

It also deeply troubles me that no one from Canonical has so much as uttered a peep about this. These are issues fundamental to Snaps and it’s going to take someone from Canonical to implement fixes.

11 Likes
5

Note from the Moderators:

This important topic started out with a rather clear purpose:

There are several reasons why discussions may wander into un-productive territory. Let’s all please work together to avoid those weeds and keep the discussion on-topic and constructive.

Thank you.

1 Like
6

That’s universally fair guidance - and I would respectfully suggest that nothing in this thread so far is off-topic. The underlying topic here - deeper than “there must be emails listed for each Snap” - is how to create effective paths between and among:

  • End users
  • Community Snap packagers
  • App developers
  • Canonical Snap packagers
  • Canonical Snap infrastructure builders/designers

IMO the fact that many programs in the Snap Store don’t facilitate easy identification of the packaging manifest, who to contact for support, etc. is a symptom of an underlying cause that there isn’t an active relationship across many of those intersections - seemingly more of a “the tools are here, please use them to do good things” approach in the developer/packager direction, at least.

And also IMO, this is also relevant to Ubuntu separately from Snapcraft because, while the originating statement is Snap Store-specific, the underlying topic impacts the Ubuntu community for some core questions:

  • Users: How do I safely and effectively find, install and update software on Ubuntu?

    • When should I trust the provenance of a Snap? When should I trust an Ubuntu .deb repository package?
    • Who supports each application?
    • When should I choose one over the other when both are available? (Is Ubuntu Pro relevant here, etc.)

  • Developers & Packagers: How do I get my software to Ubuntu users?

    • When should I seek inclusion of a package in Ubuntu’s .deb repositories? When should I publish as a Snap? What is Canonical’s level of support of me as a developer/packager for each?

Another, perhaps simpler way to look at it - are the folks who are the “heroes” of the community, doing the most hands-to-keys work, happy with how things are going? I’m obviously not one of those folks, but seeing some of the names that are coming up in that Snapcraft forum thread expressing unmet needs would tell me that something deeper than “adding a required field to Snap Store metadata” is going on and needs addressed.

10 Likes
7

All that is kind of built into the process for getting a deb package in the Ubuntu archive. I think we need something similar for Snaps. I guess the best analogue I can give is that we need more of the Apple App Store than we do the Google Play Store. More curated apps, less of a free for all.

8 Likes
8

I will repeat the Oracular ISO test when desktop-bootstrap changes and for this I would like to have something similar to ‘apt changelog’ but ‘snap changes ubuntu-desktop-bootstrap’ doesn’t help. Thank you.

9

I think this is a good idea to improve snapd, but probably not all that applicable to the topic at hand. This isn’t really a “brainstorm improvements to Snaps” topic so much as one about some very fundamental things about Snap infrastructure. I think the core of it all is best put by @johnandmegh above.

1 Like
10
12

We do have such place, but it’s not properly exposed. We’ll definitely work on it.

13

I share the concerns raised in this discussion about the need for better support paths for Snaps. The Snap Store would benefit from more thorough reviews and scrutiny, focusing on hosting high-quality software that meets user needs. Emphasizing quality over quantity is crucial.

The root cause seems fundamental and prevalent in the open source and FOSS community, particularly around end-user desktop software. Many Snaps are one-off projects by hobbyist publishers. Most desktop software in the Productivity category doesn’t meet enterprise requirements, catering only to basic user needs. This category includes the “usual suspects” like commonly used web browsers and then LibreOffice, which often fail to meet modern enterprise expectations and are not preferred or wanted by many enterprise end-users. A few lesser-known email and office suites are also available, but they too fail to satisfy user requirements, and the abundance of simple “to-do list” and similar apps doesn’t add much value.

The Gaming category is actually a prime example, filled with FOSS indie games that don’t meet today’s standards for quality and engagement, questioning the value of this category.

The only categories consistently offering high-quality software are those targeted at technical end-users, such as Development and Server/Cloud categories. This is likely due to the high general adoption of Linux in these highly technical areas. Other categories could benefit from more diversity and innovation.

While the Snap Store has its strengths, improvements are needed. Focusing on quality and ensuring software meets a wider range of user needs will enhance user experience and trust. This benefits both users and developers.

Apple’s App Store and Google’s Play Store, while serving and selling different types of software (mobile apps), have stringent app requirements, which could inspire the Snap Store. For the Snap Store to be taken seriously, especially in the Productivity category, it needs high-quality desktop software from well-known vendors. Imagine Canonical partnering with Microsoft to enhance the user experience with Microsoft 365 on Ubuntu. Such strategic partnerships could significantly improve application quality and the Snap Store’s reputation. This approach has worked well in the Development category in the Snap Store, with several high-quality Microsoft desktop-oriented applications targeting developers using Ubuntu Desktop.

6 Likes
14

My comment about the Apple App Store and the Google Play Store was not about trying to “meet enterprise requirements.” It was about how with the Apple App Store, apps are carefully curated. That isn’t to say it doesn’t have a lot of the sort of software described as being problematic.

Maybe it’s not the exact comparison I’d like, but it’s better than the Google Play Store, which is exactly what the Snap Store is: a total free for all. And THAT is the core of this whole topic: not only is the software itself a total free for all, but so is the store and the entire packaging format.

2 Likes
15

I would disagree to an extent. I’ve been packaging FreeShow on behalf of the developer for years now and every time there’s an update, I get it snapped within hours of the release.

1 Like
16

[Edited by Moderators]

If we look at FlatHub, you have a public issue tracker, a public repository of all the files and components so you can experiment, a method to contribute and a public list of all the changes.
So that makes snaps quite different in this regard.

2 Likes
17

Putting my moderator hat on for a second. As @ian-weisser stated:

This includes Flatpak vs Snap debates. The moment this conversation even looks close to going into those weeds, we will remove those posts. You are entitled to those opinions, but the scope defined by @wxl in his original post in the topic was narrow.

4 Likes
18

But I completely agree with @ernstp there are many big broken snaps, that we can’t do anything other than just mail the company in the hope that they’ll fix it. Some examples are

This snap simply doesn’t login to the user account

This snap is still using core18 and we can’t fix it. Also, the startup of this snap is very slow and we can’t do anything about it. Probably they don’t use lzo

This snap doesn’t work, but still it’s on the store

This snap is not at all usable, still this is on the stable channel.

How many more examples do we need to show up to say that the quality of the apps are not at all good! This is reality! People are forced to use other formats for these!!!

2 Likes
19

I too would like a simple way to report errors or bugs in specific snaps. The Steam Snap for example refuses to launch many Proton games that DO launch on the deb version.

The game reporting (canonical/steam-snap Game Reports · Discussions · GitHub) could be made bit more front and center inside Ubuntu? This place of reports is not obvious find for everyone; a link “Report a problem with a specific game” in the App Center (on the page one installs Steam Snap) would be easy to add. Or something such.

Just an idea. It’s important that the gaming experience is smooth as possible for new users to Linux (who in great numbers choose Ubuntu)…

5 Likes
20

To that list I would also add Inkscape snap, which can’t save files properly. This bug is known but no repair action was taken by maintainers of software (it’s official Inkscape snap btw) as of now:
https://gitlab.com/inkscape/inkscape/-/issues/4027

1 Like
21

They are working I guess, as it seemed from the issue conversation