Wider use of content snaps

I keep running out of space on my machine, so I wanted to know why. It turns out there’s a lot of duplication across many snaps I have installed. Taking one library as an example, I totted up how many copies I have on disk and how much space is wasted as a result.

In summary, I have 264 copies of libLLVM-X.x.so.1 across 88 snaps which comes in at 3.81GB of disk space. Each copy is between ~39MB and 58MB uncompressed, but as we’re using squashfs, they’re actually between ~11MB and 17MB compressed on-disk. That adds up though, and I only looked at only one .so file. There are many more which are duplicated across numerous snaps.

This particular .so file is pulled in by the need for openGL capability via mesa drivers. Any modern desktop application is going to need this, and many other files. I can mitigate this a little by reducing the number of revisions of snaps kept on disk. I’m currently using the default 3, but even going down to 2 will result in me still having 2.54GB taken up by 9 different versions of this one library.

I don’t like having to micro-manage my disk space because I have hundreds of copies of the same library on disk. As we snap more things, this will only become more of a problem.

What can we do to mitigate this?
Should we have a “mesa” content snap?
What about the other libraries we’re bundling which we end up duplicating?

8 Likes

+1

Mesa feels like something we should handle like other hardware-specific userspace code (aka “drivers”).

2 Likes