I’m currently working on building a snap for restic (backup program) which is distributed as a static binary on github. The author has setup a build.go file that does a ton above and beyond the traditional go build main.go.
The real question here is:
Should a person work through to get the app to build from source, or write the snapcraft.yaml to just wrap up the static binary?
My gut says build (future proofing). But wanted to confirm what others thought.
Now his instructions to build from source state to do something like:
$ go run build.go --goos linux --goarch amd64
# or
$ go run build.go --goos linux --goarch 386
Reading over the snapcraft docs on the go plugin, there seems to be only a few options such as go-packages, etc, and states that a package outside of main wouldn’t be useful either.
I’m currently reading through the build.go to decipher what it is actually doing.
Ultimately it seems like I need to find a way to run the above commands against the build.go, yet account for 386 and amd64.
I noticed in an initial test build that it was pulling down golang 1.6 (by default, when I know the app needs >1.8. (was using a cleanbuild environment). I know there is a V1.9 golang snap in the store. Is there a way to leverage that in my build process? Although I know go 1.8 is available via APT - so I could likely (assuming) set that as a build dep.
Sorry if this seems like simple questions, but my “devfoo” is not so great outside of basic stuff.
The answer actually depends on the preference of the developer or of the maintainer. For example, take a look at syncthing, which has a build.go and they decided to use a snapcraft.yaml template that only dumps binaries:
Thanks for the most excellent set of instructions. The author has not stated a preference - I am simply working with him to get the app packaged. I’ll ask him though.
Quick question - the dev got back to me - prefers to use the built binaries. So one thing. This is a backup program - which means (I assume) that it will need access to the entire file system. Is the “classic” interface the only option? Or is there a better method?
That depends on the upstream, too. classic adds a lot of security concerns, which makes development scary.
On syncthing, so far we have decided to only use the home plug.
I would recommend to start testing like this. And after a while, have the discussion with the community to see if they want to switch to classic and accept all the risks.
I will start out that way. But right out of the gate, I don’t think the home plug will be sufficient as it does not allow access to dotfiles. As a backup program, I’m pretty sure users are going to want to backup dotfiles in some capacity. Sure the program would still be useful to backup up your files, but severely limits the app as you cannot backup configuration (dotfiles, or /etc). Nor can you backup from an alternate user (say a backup service account for a server). It seems like this app almost “has” to be classic as it needs to be able to (with appropriate permissions) have to access to the entire file system.
In this case, it feels like snap is just a super convenient distribution system, and does not so much have a security story here.
