For simplicity sake, let’s leave the source-codes (as in, the way Launchpad did with the .deb packages) asides.
#1 Multiple arch specific snaps?
Each snaps is specific to one architecture and I’ll have to run a build script looping all the snapcraft.yaml and upstream them accordingly. This is similar to building deb packages for Launchpad.
#!/bin/sh
case "$SNAP_ARCH" in
"amd64") ARCH='x86_64-linux-gnu'
;;
"i386") ARCH='i386-linux-gnu'
;;
*)
echo "Unsupported architecture for this clock app build"
exit 1
;;
esac
NOTE: If possible, I want to avoid this step. It’s ridiculous for snap with a lot of commands.
Our snapcraft.yaml are mostly using prepare, build, install keywords for our dump plugin. We use the shell script commands to pack the binaries accordingly.
We do have a packaging script that help us automate .deb + .snap packaging for our current not architecture specific projects. We don’t mind upgrade it as long as the direction is right.
see the architectures documentation, build-on and run-on were recently added (this does not yet fully work with build.snapcraft.io though, you will have to build locally):
Based on the documentations, we’ll upgrade our packaging script towards the multiple arch-specific snaps.
That’s is the convincing way to do it while maintaining single snapcraft.yaml script.
To build arch-specific snaps, we issue the snapcraft command with the --target-arch flag and loop across each architectures. E.g.
Inside the scriplets, we chop the $SNAP_ARCH_TRIPLET to get identify the target architecture. From there, we can move the correct arch-specific binary accordingly to match the app commands. Something, like this:
override-build: |
case ${SNAPCRAFT_ARCH_TRIPLET%%-*} in
x86_64)
echo "x86_64"
;;
i386)
echo "i386"
;;
*)
echo "ailen"
esac
Side-note: the $SNAP_TARGET_ARCH idea is really helpful. +1 instead of doing manual chopping.
When up-streaming all the snaps, the store is able to identify and sort the architectures out under 1 snap name. This applies to user downloads the snap as well.
Did you read the Architectures doc above ? It changed to be more fine grained telling snapcraft with architectures you can build on and on which architectures a binary produced in such a build can run … (build-on and run-on).
There might be backwards compatibility issues though, i’ll leave answering that to the snapcraft team…
yes, i re-read it (and then opened a second topic) note the example is [amd64, i386] which is similar to what I am doing with armhf and arm64
architectures
The architectures on which this snap runs. This defaults to the host architecture unless --target-arch is specified, in which case it defaults to the target architecture. One may specify multiple architectures if that’s supported (for example, a 32-bit snap might run on both i386 and amd64 using [amd64, i386], or a snap that is shell-only might run on all architectures, using all).
Type: list of strings