Regarding (gnome-)software in Ubuntu → https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1883445
Not sure where to report other things…
I did not worry about the /dev/loops but the size of ~/snap or /snap
So the only « weighing » parts are /var/lib/snapd/snaps and ~/snap ?
right, … there is one more … /var/lib/snapd/snaps carries the snap files, ~/snap carries all user data and /var/snap carries global data or data for daemons, configurations etc … any app that doesnt get run by a user (i.e. services) will use the /var/snap dir.
which also leads to many duplicates for years… 2017 but am pretty sure this topic surfaced before here and there.
( I even forgot I had already created one of these )
That looks like the issue is known and not considered as a bug.
Though it leads to much disappointment user’s side regarding snap.
Un-productive selling strategy…
As the primary bug report for your list of duplicates states, GNOME Software does have the ability to deduplicate entries from multiple sources. It does this via “appstream IDs”.
On the deb side, this is generally handled by scraping the packages in the archive for metadata installed to /usr/share/metainfo or from .desktop files, producing indexes that get downloaded to /var/lib/app-info/yaml.
On the snap side, AppStream IDs are specified by the common-id field in the snap’s meta/snap.yaml file, and also returned in search results from the store.
When things are working correctly and both packages provide the same ID, you should only see a single result in the search results. Things break down in your Audacity example because the two packages claim different IDs. The deb package doesn’t provide any native AppStream metadata, so the fallback ID audacity.desktop is reported (i.e. the filename of the desktop file it installs).
The snap instead uses the ID org.audacityteam.Audacity, which seems to be the ID made up for the flatpak version of the app. So the deb and snap versions are considered to be different applications. The same would be true for the deb and flatpak versions.
So, who’s wrong here, the Debian package, or Flatpak and my Snap? Note that Audacity provides the metainfo in their repository, so I’m using that. If the Debian package isn’t using the provided metainfo then I’d suggest that’s Debian or Ubuntu’s fault
It looks like you and the Flatpak are correct in this case, and the appdata.xml file was omitted from the package in Ubuntu 20.04 and earlier. Looking at the diff, the package in 20.10 should correctly deduplicate against your snap:
https://launchpadlibrarian.net/478665940/audacity_2.3.3-1build1_2.3.3-2.diff.gz
This was definitely a shortcoming in the deb package rather than anywhere else.
Flagged for out-of-topic, seriously ???
(gnome-)software is the detail here, the elephant in the room is : why are snap missing adoption opportunities ? Because maybe there is nothing user’s side that brings the right info at the right moment about dealing with snaps ?
Often people install snap by accident because of ↓ how could they feel safe about them with such manners ?
Sorry @lucyllewy and @jamesh I think you both missed the point 
There is no problem with metadata or audacity here.
The problem here is how surface the many packaging-types for one given app. And how it’s actually handled is not an accident, it’s just a very old, bad and misleading design choice, that’s all. Old because it’s coming from an era when only one type of packaged app’s was available, .deb.
When searching for a particular app in (gnome-)software and given you have snap-plugin + flatpak-plugin, you may see that app listed 3× It’s not because of metadata, it’s because of packaging type.
Users seeing this are meant to make a conscious and well-thought choice between let’s say 3 app’s that all look the same. How ? On that list there is nothing to differentiate one from the other. The difference is the packaging type but there is no visual clue to explain and help people chose between snap/flatpak/deb/whateverelse → this is the misleading part.
Amongst those 3 same looking items in list, one falls at bottom of the list. It suggests something like bad ranking or an attempt to hide it from people’s view. And guess what ? The last one in the list is the good old legacy .deb package, the easiest one to use, install and manage → this is the bad part, because biased instead of explanatory.
The way (gnome-)software still works today, it seems unavoidable to propose one item by packaging type ( in fact one item by plugin ) otherwise how / where people would wisely chose between them ? Look carefully at the 2 first pictures for 2 easy ways to get rid of that confusion.
The way bug reports on this topic look ignored for years suggests there are people who think the actual situation is good. It’s not. It makes users install things without knowing ( the most ) important information, packaging-type. Packaging-type dictates how an user will have to take care of his⋅her app’s and system on the long run so it must appear upfront, not be hidden at bottom of a second page, silenced nor biased.
This presumes that the user knows and understands the differences between the packaging systems and I think is an unreasonable burden to place on someone who just wants to install software. The ideal situation is that from a usability standpoint the different packaging versions are the same and so it shouldn’t matter to most users of the software which one they get.
I think that adding additional information about snap vs deb vs flatpak in the default workflow will only confuse the user who doesn’t understand the distinctions. We should definitely expose this information to those who care about it and make it easy to choose something else, i.e. an advanced installation options page, but for the default flow I agree with the others in that different package types shouldn’t show up.
This is absolutely wrong → you don’t get the same « usage » depending of which type of package you installed. Not the same way to update them, to give permissions, etc. It’s impossible and misleading to treat those packaging as if they were « equivalent ». They’re not, each implies some specific care, even at basic level.
The actual lack of information creates confusion → user installs first item from the list → then asks in forums why this newly installed app’ can’t access this folder or that usb-thumb… because he had to set permissions. How could he know since packaging is not clearly mentioned ( in app-name or at top of a page ).
If user was right at the beginning aware of which kind of package he installed, end of problem.
If he’d been in front of a choice between [ gimp-snap | gimp-flatpak | gimp-deb ] he would had a chance to ask which one is better for him. But being in front of [ gimp | gimp | gimp ] it’s lottery, ok I take first in list, because first is probably better ???
Actual situation is intellectual dishonesty. Nothing else. Users are not that stupid if you give them the right info at the right moment. I hope (gnome-)software’s purpose is not to hide information in order to make people install snap by accident.
Oh. How pointing some obvious subjects of disappointment for users facing snap in gnome-software, leading to non-adoption of snap for such users, makes me out of topic here ?
If you were looking for some place to iron out for easier snap adoption, then the « app-store » aimed at basic users is certainly one to improve. Amongst others, of course.
… and this is what actually needs to be fixed
(in the long term)
You are implying bad intent while there are simply missing features …
I hope there’s no bad intent. But those missing features ( if we look only at the default app-store in Ubuntu made by Canonical, mother-home of snap ) were very easy to guess, have been confirmed as annoyances by many users through many forums, have been reported as bugs for years and since the beginning…
…if by accident users install a snap, and later are not happy with that snap, how do you want these users to adopt snap ? I don’t know what’s the English phrase here, but it looks like feet over head, doesn’t it ?
Though, putting snap first in the list, and deb last, was an intent : I can’t see any good here.
Improvements are real, month after month, no doubt. But for being adopted snap has to be at least as good as what people used to have without or before snap. I know snap already has more interesting features than .deb but as long as users may struggle with thumbnails or themes or translations or permissions or this or that, snap will be seen as « less good » and lose.
I really think there’s a need for a better entry point into snap-ecosystem, with an one place / one app where everything regarding snap can be known and managed : (gnome-)software fails at that, and settings/applications in (gnome-)control-center is not enough - but provides at least something that should have been provided by Canonical inside Ubuntu as soon as the first snap iteration.
Integration into Desktop Environment through a specific GUI, distro-agnostic and itself provided as a core snap. Something that takes the desktop-users by the hand and teaches, explains, helps them « taming » snaps. Is such a thing on the map for non-IT-non-Dev users ?
It really is because of the metadata provided by the packages. In the specific case of Audacity, the Flatpak and Snap packages would be collapsed into a single entry as they both have the same AppStream ID. And if you’re on Ubuntu 20.10, the deb package would also collapse down too. I don’t think there is a situation where you’d see three entries in the search results in this particular case.
If we look at the internals of GNOME Software, there is a gs_app_list_filter_duplicates function that can deduplicate a list of apps based on AppStream ID:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/lib/gs-app-list.c#L777
When there are duplicates, it picks the one it considers to be “best” and discards the rest. This is determined by a priority scheme based on information provided by the plugins. In particular, the Flatpak and Snap plugins for GNOME Software state that their search results are better than those from the PackageKit plugin (which is how apt packages are plumbed in):
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/plugins/flatpak/gs-plugin-flatpak.c#L52
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/plugins/snap/gs-plugin-snap.c#L131
This is down to applications from these sources generally being safer and more up to date. There’s no specific ordering imposed between Snaps and Flatpaks, so I don’t know which one would win or if the result would be stable.
Ok, that’s very interesting, thanks. But doesn’t all this apply only to front page of « software » ?
So if the « de-duplication » was all the way down- where people will chose which type of package to install ? The packaging type must finally appear somewhere, for users to decide.
Anyway you’d agree it’s not actually like that on LTS 20.04 - so let’s hope future improvements to (gnome-)software will get backported.
Today if you explicitly are searching for Firefox, you might see many Firefox listed, and no clue to differentiate them on that list. I don’t talk about the front page here.
This code path is run for search result lists. You should only see search results for things like “gnome-calculator” and “gimp” collapse into a single entry, even though they are available from multiple sources.
Hi, Is there any chance to get those things fixed for point release 20.04.1 ? So that inside Ubuntu Software every app got just one entry and after you have select it, you can select deb or snap version from the top right drop menù.
I’ve tried PopOS and it works like this, showing the option for deb/flatpak.
Some other aspects:
If you uninstall snap-store and then you run:
sudo snap snap-store
you are going to install a different version from the one pre-installed (different icon, not able to install deb).
deb2snap
If you are trying to install Chromium with apt, it would be much better to receive a message like this:
Sorry, a deb package for chromium-browser is not available, but you can install a snap version.. do this.. do that..
Changing the behavior of a command is not a good idea. Actually, it’s the fastest way to make people angry.
If someone is opening the terminal (not Ubuntu Software) to specifically install a deb but what he automatically gets is a snap… it’s quite predictable he will be annoyed, even if he has nothing against snap.
There’s also a snap folder affair. Maybe there’s a valid reason to set the snap folder visible inside the user’s home. Anyway, it’s true that it looks like an alien, it could look better as hidden folder.
Basically the ubuntu software looks unfinished to properly reflect a hybrid deb/snap system. It looks like Ubuntu should be used only with snap apps, not taking in consideration that some snaps might not be 100% ready to substitute the relative debs. Also it has been underestimate the fact that there are users using small partitions. We had noob users in the Italian Ubuntu forum with the system not able to update or install new software, because the partition was full. They didn’t have any idea they were installing snaps, which are heavier than debs. Of course they should have used bigger partitions, but take in consideration that for ages that wasn’t a problem because one of the magic of Linux was that it didn’t need much space.
It’s a transition time, it might take a bit before most of the users get used to this new technology. I hope it will be possible to ship the next point release with some useful improvement 
Sorry if I sounded rough, but… it’s because I care (by the way I’m in the Italian Ubuntu community since 2006 and I’m looking after the ubuntu-doc wiki).
It’s a pity to see so much criticism against Ubuntu, while generally speaking the 20.04 release is just amazing… one of the best release ever
…so now there’s single entry there must be another « place » for choosing which packaging-type to instal. This sounds like ↓
…if it’s hidden behind a drop down menu, it’s still not enough self-explanatory. But better than actual situation.
Yes that’s right, but I think Snap Store’s design will not change soon. The drop down menù is an original feature and it was actually working in gnome-software when I tried it in April.
If they could mange to fix the bug…
yep!
I wrote a draft FAQ. I hope this or something like this can be used:
Q: Is Snap open-source?
A: The server, which is what we use to host the Snap application repository, is closed source. The client, which is the part that is installed on your computer, is open-source.
Q: The Snap server code should be open source!
A: From past experience with Launchpad, there is no real demand for hosting a 3rd party snap server, and no real interest to contribute to it. Opening it up would introduce an extra cost and come at the expense of development, so unless presented with a good reason, it won’t be done. Appeasing the haters and removing an excuse for attacking Snaps isn’t a good reason.
Q: There should be support for using other repositories!
A: There is a benefit to having 1 repository that has all the apps. That way users don’t have to worry about repositories, it just works and everything is there. It’s also more secure as the Snaps all come from one secure source instead of myriad source that may be questionable.
Q: It should be possible to disable auto-updates!
A: Our goal is for things to just work transparently for the user, and out-of-date applications are a security risk for the user. As for problems caused by auto-updates breaking apps or causing disruptions, we have introduced the ability to choose update windows, delay updates for up to 60 days, and manually rolling back an update for a single app, which then disables automatic updates for that app.
Q: Snap applications look alien on my system.
A: Some theme include executable code. Making Snaps just use your theme would represent a security risk. This problem has been mitigated by the creation of theme snaps, and we’re working on making it better.
Q: Snaps are Ubuntu-centeric!
A: We put a lot of work into separating the Snap brand and system from Ubuntu, making it disto-agnostic, and providing full support for a wide range of popular distributions.
Q: Snaps are slow to start!
A: Unlike traditional applications, Snaps need to set up a runtime environment in which they will be run. This will unfortunately mean Snaps will always be slower. Our goal is to make the start up time fast enough that the user won’t notice it anymore, and we have made great progress towards that goal.
Q: Snaps take up huge disk space!
A: Snaps are saved on the disk in a compressed format which reduces the disk space that is being used to around 1/3 of the uncompressed size. They may look big if you look at the size of an app at /snap, but that is a mounted filesystem and shows you the uncompressed size. It’s not the real size on disk. We are further working on reducing disk size by detecting and eliminating duplication of common dependencies. Also, Snap uses delta updates, so updates are much smaller.
Q: Installing Chromium as a Snap when users use Apt to install it is a disgusting sneaky attempt to push Snap on an unsuspecting audience!
A: Since we discontinued our efforts to ship Chromium as a deb package in favor of using Snap for delivering applications, we we’re left with 2 alternatives: Leave users who have Chromium installed with an out-of-date web-facing application that will increasingly become a security threat, or to turn the Chromium package into a transitional package so that existing users will be transitioned to the Snap version and continue to enjoy an up-to-date and secure application. We chose to do what we thought is best for our users. Also, the package description clearly states that it is a transitional package and that Chromium will be installed as a Snap.
Q: Which advantages do Snaps offer over traditional applications?
A:
• Secure confinement so that a Snap can’t do anything that the user hasn’t allowed…
• Delta updates, so once a Snap is installed updates will use very little bandwidth.
• Confined installation, so that the Snap doesn’t modify the underlying system or modify other applications.
• Snaps run in their own runtime, so that future operating system releases will be backwards compatible with old Snap applications.
• Cross distribution, so package once run anywhere.
• Separation of the applications from the base operating system, so that users can enjoy up-to-date applications on stable and LTS systems.
• One place to publish Snaps and one place to get Snaps. No confusion or fragmentation.
• The ability to have multiple versions of the same application side by side, and to easily roll-back updates.
Why we are wrong to think snaps are wrong, isn’t it ?
…is a disgusting sneaky attempt to push Snap on an unsuspecting audience
This is less disgusting than an app-store that puts snap first on list and push back legacy .deb packages at the deep end, showing both without differentiating them, without showing package-type upfront and therefore leads people to install snap without noticing it, as if it would not require special attentions ( at least, permissions ).
This looks like getting improvements, but packaging type should never be hidden, if you obviously want to give people « awareness » of what they really install. And permissions should be dealt with at first launch of a snap app, pointing user towards the right page in software or (gnome-)control-center or the likes. A snap-manager somewhere, somehow ?
The Q&A is a good idea. But better idea is to improve usability and informative-ness of app-stores. Be user-centric. Give users a one place for all actions and information regarding snap. Show users the eventual benefits of snap right there on the screen in a fancy GUI instead of hiding them away in CLI and forums and web-pages.
And when people tell « I have this or that problem with my app » just acknowledge there’s room for improvements as obviously if people complain, it’s because there is something unexpected or less good compared to legacy / usual .deb packages, from a desktop-user’s point of view.
Yes users are no dev’s, are no IT-people, but they might be high skilled in their trades/professions and need work be done efficiently with their computers. Do snap answer those needs better than other packaging ? I can’t see why but maybe.
Snaps take up huge disk space!
So there should never be situation where an user gets a frozen system where folders related to snap lead to full partition ? ? ? It seems to happen though. I’m not talking here about the /dev/loop* but /var/lib/snapd/snaps or ~/snap and /var/snap. Those easily get very very huge. How will those affect the system ?
