If a DEB exists for something, do you guys build up from the DEB, or from source? Is source considered best practice and a DEB (build) is a fallback? Is there a pro/con one over the other?
As always “It depends”. 
If it’s a proprietary application which already has a deb built, and the vendor doesn’t have the resources to look into snapping their application right now, then ingesting the deb and making a snap from it is certainly an option. However the ideal scenario is that the yaml lives in the upstream source tree, which is hooked up to their ci system whether that’s travis, circle-ci or some other thing, and spits out a snap. That snap can then be pushed directly to the store edge channel for adventurous users.
If you’re talking about debs included in a build of something else, we often use stage-packages to pull in things from the archive, but ideally we should be building from source each time. stage-packages is really a convenience, as it’s way easier to just specify a stage (or indeed build-package) than work out the necessary parts one by one, with all their build intricacies.
Personally I’d like to see us move all our things to source-based builds rather than stage-packages and build-packages, but building all of the world every time is a massive consumption of resources, so a balance needs to be struck.
1 Like
Thanks, @popey.
This decision is an easy one to solve (source vs deb). Haha. It is budgie-welcome in this case. I have been building out from source, but another team member has been playing, and their version was being built out using the DEB (easier, faster to get running).
I just wanted to ensure that we went the route of best practice.
The clarification is appreciated.
I disagree. You’re quite correct on the time argument, but building from the deb not only means you can build snaps faster, but it also means that you pull in other aspects of your distribution’s packaging - e.g. security hardening via compile flags. By building from source, you’re throwing away years of effort that the distributions have put in to taking software and making it suitable to end-users, who often have no idea how to compile software.
I, for one, would not like to implement all of https://wiki.ubuntu.com/Security/Features by myself for every snap. You should think very carefully before “just” building from source.
It looks to me that all those features are either in the kernel or via a patch on GCC. If you’re building on Ubuntu then you’ll get the GCC patches the same as Ubuntu does because you’re using the same GCC binary. If you’re shipping your snap on Ubuntu you’ll get the kernel from Ubuntu. If you build or ship on other systems then you’ll get the build environment or kernel of that system.
I respectfully disagree with your premise that we’re “throwing away years of effort” by compiling our snaps rather than unpacking a deb and then repacking it into a snap.
Yes of course, you will get the benefit of some of the toolchain fixes when building on your target platform, but there are also patches that are maintained by the distro (be that Ubuntu or Debian or …) to the build scripts and even source code of the packages which should be carefully considered.
To be clear, I am not advocating that snaps should be a straight copy of their corresponding debs - perhaps incorrectly, I assumed that OP was asking about dependencies.
I do think that, where possible, dependencies for snaps should be first sourced from the Ubuntu archive to get all of the “Ubuntu goodness” that has been baked in to the packaging, and I can benefit from the work already done by existing Ubuntu teams. e.g. if I’m snapping software that depends on PostgreSQL, I do not compile PostgreSQL, since it’s already packaged. This means the Ubuntu Security team can notify me when there’s a CVE for PostgreSQL (see Snap updates and developer notifications on security updates ). I get to concentrate on building /my software/ and encoding it in snapcraft.yaml whilst leaning on Ubuntu maintainers (and upstream) for my dependencies.
I see. Yes I tend to rely on the dependencies coming from the Ubuntu repos where available, too. However, I have also compiled more-recent dependencies where an application will benefit from such. e.g. my Corebird snap includes the color emoji support from the latest fontconfig which isn’t currently packaged in Ubuntu, so I compiled it myself to allow users of the snap to benefit from the awesomeness now rather than waiting until Ubuntu repos catch up with Bionic and Core Series 18.
For me, I only build from source if certain parts from DEB is incompatible (too old or too new), not relocatable (requires rebuild from source to set the proper resource search path), or requires further patching