I publish the boa snap, which is already fairly chunky at over 500MB. The final release of the game is due in the new year. A combination of the new game assets and performance optimizations such as lzo compression have made my work-in-progress snap nearly 1GB.
There are several thousand users of this snap. I suspect at least some of them are going to have a nasty surprise when snapd automatically archives the old version and downloads and installs this much larger revision, which will consume much more disk space. That will be compounded at the next update, when the large revision gets archived. A user who has had only one revision of the original snap installed is going to find it is now consuming 4 times as much disk space.
Should snapd warn a user before a much larger snap revision is going to be downloaded? Is there a graceful way to handle this?
You could instruct users to run sudo snap set system refresh.retain=2 which configure snapd to only store 2 revisions of snaps rather than the default of 3.
Overall though, I don’t feel that using up to 3GB for 3 different revisions of a game is that much. Steam games can go well beyond 100-200GB+ of space these days, and automatic updates are generally expected of games in general on basically every serious gaming platform. The revision history might be somewhat unique to snap, but otherwise constant bandwidth usage to games is on the whole pretty normal (and snap is transactional so efficient for raw bandwidth anyway).
There’s certainly a worry about not needlessly wasting space in general, but I think 3GB is far too low on modern desktops to worry about optomising boa specifically. If the system begins to run out of space, it’ll generally warn the user and on systems like Ubuntu have facilities to show the exact folders space is being consumed and it’ll point fingers at snap if needs be, but I think generally massive video files and games and music libraries are more likely to be the issue than any singular snap.
If we were talking using 3GB of space for something like Vim, I might have your concerns. But I think for boa itself, you’re probably well within user expectations.
As a tangeantal aside, I have the runescape snap. The snap is a 120MB download, 360MB across 3 revisions, but downloads the game assets at runtime, these assets used to be about 8GB on disk, though they were recently reduced to 4GB. They aren’t included in revision history. To date, no one has complained about it, I’d wager because a working game is a working game and space for gamers is cheap.
Thanks James. That’s a rational perspective, and you’re probably correct that I’m worrying too much about this. On the other hand, I’m not sure that the users installing games from the Software Centre are the same users installing multi-gigabyte games from Steam. On my spcae-constrained laptop I’ve already struggled with the swelling of the ScummVM snap when the decision was made to bundle the freeware games and demos.
I’m unfamiliar with boa but it might make sense in some scenarios to split up snaps, ScummVM could potentially have had a second snap containing the extra assets and declared a content sharing interface allowing you to split apart the two and potentially just not have the demos, of course the content snaps would end up having revision history so it probably doesn’t make sense for Boa if space alone is the concern.
I think aside from waiting for other compression options with better compression ratios, the most obvious choice it to download the assets distributed outside the snaps filesystem itself, but this comes with the problems of hosting, more complex setup procedure, keeping the assets updated seperately to the snap itself, etc.
I just took a look at the steam stats, 1.16% of Steam users have less than 10GB available, although I’m unsure if this is counted across every drive or simply the OS’ primary drive which makes this fairly ambiguous (It’s not too uncommon for people to have a faster SSD for critical apps and slower SSD’s or harddrives for things like games, and I don’t think snap makes it trivial to decide which drive snap files are stored in so this could be a big factor here).
I see your point of different expectations in the software center vs a client like Steam itself, but the software center is never particularly straight forward when people might have different download sizes on the orders of several hundred MB over shared dependencies. A snap has an an absolute calculated size on the harddrive shown in in the software center as size of the snap itself minus its base/extensions/etc, whereas a small 10KB Java game might be a 100MB Java game overall if the user doesn’t use Java otherwise. In that sense the snap is more truthful, so I’m unsure the software center is amazing for reporting disk space usage in general.
Edit: When filtering the steam stats to Linux only, there’s 7% of the userbase with less than 10GB available. This does begin to seem more concerning but it’s still ambiguous how the stats are counted (multiple drives particularly, given how Linux systems tend to use multiple partitions mounted under the common / directory).
