@Lin-Buo-Ren, please keep me honest here and correct anything I don’t have right.
If I were you, @Szyk, I would sudo apt purge --remove both multipass and snapcraft. Then:
snap install snapcraft --classic
snap install --beta multipass --classic
The snap versions support the core option and I’ve generally had better luck with it.
Use the latest snapcraft.yaml I posted today.
Then:
cd Kopia3
snapcraft clean
SNAPCRAFT_ENABLE_DEVELOPER_DEBUG=yes snapcraft 2>&1 | tee snapcraft.log
My log: https://pastebin.com/cfyFFfez
When I’m debugging, I immediately get a shell into the VM snapcraft creates (snapcraft-kopia) and then sudo su. Then cd /root, where you’ll see the snapcraft directories. In particular, the interesting directories for me are usually:
/root/parts/<part>/install: These are where the important bits of your parts builds end up. Stuff gets in here because snapcraft does the equivalent of make install DESTDIR=FOO/install, where FOO is the path to /root/parts/<part>/install. If your build doesn’t support that kind of make command, you can override the build like this:
parts:
foo:
override-build: |
snapcraftctl build # for housekeeping
make foo bar baz
cp ./Kopia $SNAPCRAFT_PART_INSTALL/usr/bin/.
Many, many snaps override build and use SNAPCRAFT_PART_INSTALL exclusively, although I’m sure this is discouraged officially. My general philosophy is that you shouldn’t ever have to change the way your project is built to accommodate snaps. Sometimes, projects have quirks or requirements that don’t fit into the general model snapcraft assumes for specific project types. For example, in one project of mine, I have to override the “gradle” build because I need to use a specific version of Java, which I set with JAVA_HOME in the override-build script. The default “gradle” plugin won’t work for me in that case.
So the first step is to really go part by part and make sure everything is working by part at first.
Then, you can start worrying about:
/root/stage: This is the staging area where all the parts install stuff is compiled together for the first time. If you have overlapping files, you’ll get errors because snapcraft doesn’t know how to resolve them. If stuff doesn’t show up where you expect in stage because of the way you’re building things, you can organize the files to change their location in stage:
parts:
foo:
...
organize:
usr/bin/my-built-thing: usr/local/bin/thing
...
Note that those paths are relative to the stage directory.
Note that you should include everything that part will need to run at run-time under stage-packages and everything your part needs to build under build-packages. Don’t worry about the same packages being used in different parts. That’s okay. Think of the process as distinct part install file systems being overlayed in layers in stage, where things are then organized (organize) and copied to prime, where they are snapped.
Finally, everything ends up in prime, where it is snapped. I’m sure there are a billion details I’m not mentioning that might be important, but generally speaking that’s the flow that makes it work on my machine with my environment (i.e. snap versions of snapcraft and multipass in 18.04).
Hope that helps.
