I was installing Gimp in Ubuntu 20.10 Groovy Gorilla via snap, and was shown this message “Automatically connect eligible plugs and slots of snap ‘gimp’”.
Even after gimp got installed, I noticed that a huge amount of downloads were continuing. A bit of Googling showed that snap was downloading all sorts of other peripheral software for gimp.
So I have two sincere requests: Request1: Please understand that many people live in third-world countries with hopelessly slow and restricted internet connections. For example, I have an internet connection with a daily limit of 1.5GB, and the speed is just 2MBps to 5MBps. So what may look like a tiny download to you, is something that can be crippling for me and many others. For any snap download, please show the exact number of MB it will take, for the download. Also, if there are any extra peripheral software to download, ask for the user’s permission and show how many MB it will be, instead of downloading it without asking permission. Request2: Many users have already complained on various forums about how snap performs an auto update. This results in the same problems for us, as what I’ve mentioned above. So, instead of doing an auto-update, please show the user a message, asking for permission to proceed with doing an update (and show how many MB it will consume) and also offer a GUI option to allow the user to schedule the update at a desired time or to disable it. I’m aware of the commandline options to schedule an update, but a GUI option would be a lot better.
For now, I’ve uninstalled snap. Please consider and implement what I’ve mentioned. The idea for snap is good, and I like that it comes pre-installed with Ubuntu. However, there are these few things your team needs to do to make it usable. You could have a look at the AskUbuntu forum for more hints on what could be improved.
If snapd downloads additional software, it normally tells you about it in your terminal, if gimp downloads something after install (plugins or whatnot) this is something to report against the gimp snap (snaps give the packager full control here)… you can see details about whatever snapd does/did via snap changes (and more details with snap change <change id>)
To manage updates you could use the refresh.hold option or schedule an update to a convenient day with refresh.timer … also if you are on a metered connection that NetworkManager can detect (i.e. an LTE link) you can use refresh.metered …
and lastly … snaps do only delta updates, so after your initial install only binary deltas come down the line … if 5bytes changed between two revisions only these 5bytes (and some http chatter overhead) will be downloaded …
I don’t believe this is true. It’s not only deltas. The store determines whether a delta is delivered or not, and it’s not as cut and dried as “always”. From what @roadmr said in a related thread recently.
Ok, fair enough. I’ll see if there’s a forum where I can post about the gimp snap. However, do remember that other applications may also do such extra downloads, so IMHO, it’d help to design snap with a way to display the total download size, keep track of the download and give more control to the user.
I noticed that Windows detects cellular internet as such, but Ubuntu just treats it as ethernet (USB tethering). So snap wouldn’t know it’s metered.
All in all, hoping there would be changes to snap that account for what I mentioned in my first post.
You can set a connection as metered in network manager, and snapd can respect that. I agree that snapd should show total size including content snaps and core it may need to download.
This is most likely snapd downloading other snaps to satisfy the base snap and auto-connectable content interface plugs of the snap. It seems unlikely to be a download triggered by code within the snap itself.
Maybe it would make sense to extend snap download to optionally download these dependencies. It’s kind of a tricky one, since dependencies like the base snap or GNOME platform snap will often already be available, but if they’re missing can be quite a large download.
yes, that is what i meant by “snapd tells you what it is downloading in the terminal” it clearly does that for me here (it could admittedly be more detailed, but i definitely see the gnome extension being downloaded for snaps using them on a fresh system) …
It doesn’t tell you before you already initiated the install/download though, which is the problem here. A user on a limited connection could snap install spot (a 5MB snap) which triggers a download of core20 (64MB), gnome-3-38-2004 (255MB) and gtk-common-themes (68MB). So a “Oh, that’s only 5MB” could turn into 5+64+255+68=392MB download without you knowing until it’s too late.
I think this is a perspective thing. You’re not seeing the issue here. Run apt install foo and it tells you up-front what it’s going to install and how much space it will take up. Run snap install foo and it doesn’t tell you about the extra 300+ megabytes of download until after you commit.
In addition in Snap Store (GUI) you also get zero feedback about the additional downloads. So while it does tell you about the additional downloads, from a user perspective, they didn’t ask for that, weren’t told about it, and thus this is “secret” or “under the covers” install. However well meaning, that’s the perspective.
The size of the snap is accessible (eg. via snap info) so this is something we could use. However, the content snaps are discovered a bit later in the install process, after we’ve alreay fetched the snap IIRC. The base may be known earlier if I’m not mistaken, so we could query that too.
There’s only the download speed and how it will take. Once the status is updated to reflect subsequent install steps. Admittedly, when a content snap is being fetched, the status is not correctly updated to show the download status.
I’ve definitely seen cases where snapd doesn’t show the download progress for a dependency. I could see a task for the download with snap change $change_id, but that wasn’t the task the snap client decided to highlight in its progress bar.
But as Alan said, if someone is using the snap download, ack, install workflow it is probably because they want the data transfer to occur on that first step. We aren’t really providing the tools to let them do that when base snaps and content interface plugs are involved.
Exactly! That, and the automatic updates that could perhaps use a GUI for configuration or ask user permission before performing an update (and display how many MB the update would consume. If it’s too large, perhaps it could be downloaded in phases)…and maybe allow the user to set an update schedule while the user is asked for permission.
There is a gnome extension that helps a little with managing the refresh scheduling (within snapd’s boundaries, i.e. forcing an update after 60days of delay and such)
