I am experimenting with snapcraft, trying to package an applicaiton with pre-built binaries and an installer script. One of the problems that I am encountering is that the application is huge (tens GB). Pulling, building, staging and priming the application ends up basically copying its content everytime, multiplying by four the disk space needed by snapcraft and taking a lot of time just for copying things around. Is there a standard way to make the artifacts in parts/xxx/install moved into stage and then again into prime rather than copying them?
I don’t have experience snapping apps that are this big, so fair warning, these are just some untested ideas. I would try this:
- Build the snap without the large assets.
- Unsquash the snap into a local directory (it will probalby create a directory named
squashfs-root). - Copy the large assets into
squashfs-root - Run
snapcraft pack squashfs-root(the pack subcommand creates a snap from a local directory)
Alternatively if you build the snap with SNAPCRAFT_BUILD_ENVIRONMENT=host. Then you could define your part’s source as a subdirectory without any large assets in it. This would prevent the large assets from getting copy from source to build, to stage, etc. At the same time if you’re using host as your build environment, you’ll be able to use relative paths to access the assets and copy these files directly into the prime directory.
I’ll be interested in hearing your solution when you get this working. 
Hi,
I ended up putting aside that huge thing and trying to train myself on a 3-4 GB commercial application. It does not work on current ubuntu but used to work on 16.04, so I thought that trying to package it as a snap could have helped.
In the process, I tried to solve the same problem: avoid duplicating stuff since 3-4 GB multiplied by 3-4 times is still a big deal.
Got some success with override scriptlets and could actually build the snap from snapcraft, so that may be the way to go, even if it really involves a lot of scripting.
Unfortunately, the experience did not end well. The application may really be troublesome and in the snapcraft environment it keeps crashing with an XCB threading related issue, that I really don’t know how to tackle, not having sources nor support.
The biggest issue that I have encountered is with multipass, though. Every odd time it starts failing with inhability to talk to its message socket and the only solution seems to be removing its snap and reinstalling it (stopping and starting the daemon does not fix the issue), which is really a pain. I may try again later when multipass is less fragile.
If building on a filesystem that supports hardlinks (considering you are on Linux or from the multipass comment, you probably are), then hardlinks are used instead which means the multiplication factor with regards to space is not that much, operatively though, if you have many many many files, it could take some time.
A combination of override- and just doing everything in an override-prime might be something to explore for this snap.
If you are on Linux, and until the issue you have is fixed, you can snap install lxd && sudo lxd init, then just snapcraft --use-lxd