Linux - Investigate 'snap' package format

[bobsummerwill]

From @bobsummerwill on June 15, 2016 4:29

So Ubuntu 'snap' packages are usable on Ubuntu*, Debian, Arch, Fedora already and are being validate on CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt and RHEL.

That is hugely interesting to me.

https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/

Perhaps we have a path to a near-universal binary delivery format for Linux distros here?

What needs to be installed for snap packages to be installable? Will support be available for older and LTS versions of the distros?

Copied from original issue: ethereum/webthree-umbrella#590

[bobsummerwill]

From @LefterisJP on June 15, 2016 7:45

This is obviously of huge interest to us at slock.it too! Commenting to follow the issue :)

[bobsummerwill]

From @nerdralph on June 23, 2016 23:46

They look a lot like docker containers, which is good and bad. Good is the portability (since the package contains its dependencies), but the bad part is bloat.

I think it would be better to get static linking working with all the non-system libs. All Linux distros in the last 5 years should have libc6, so it should be possible to keep libc dynamically linked, if linking it statically increases the size too much.

[bobsummerwill]

Yes, you could be right.

The good news is that static linking is well underway (ethereum/webthree-umbrella#495) and is a priority for my own cross-builds too (http://github.com/doublethinkco/cpp-ethereum-cross) because just GLIBC differences are a killer there.

See doublethinkco/cpp-ethereum-cross#20 (comment).

I have heard that glibc doesn't really support static linkage, so was considering musl as the most likely solution there, following its successful use for a static binary on Alpine. Beyond that, versioning of GLIBC is an issue. Tizen 2.3, for example, for the Gear S2 smartwatch, only has a GCC 4.6.1 era glibc.

But yeah - an all-in-one executable makes deployment trivial. That's what geth does, as go-lang does everything statically, I believe.

I am relatively new to Linux development, having been Windows-hosted for many years, and the dynamic linkage pattern endemic to Linux does really bother me. It really feels like it trying to solve problems of a different era. Windows apps (especially .NET) have been self-contained for years, and side-by-side installation is an expectation even when using assembly caches.

Having executables pointing to a hardcoded /usr/ path, with symlinks pointing to .SO files, and those being globally updated just feels horribly dangerous.

[bobsummerwill]

From @nerdralph on June 24, 2016 3:32

It's getting a bit off-topic, but you are right about it solving a long-ago problem. With shared libs and demand-paged loading, 20 years ago Linux could perform well with 8MB of RAM, while Windows was barely usable with 8MB.
However some things need to be shared for functionality; i.e. auth stuff like libpam.

[nerdralph]

I've taken a break from trying to get ethminer statically linked. It's a lot more work with cpp-ethereum than with Genoil's fork. The biggest issue is that ethminer isn't a standalone git repo, and doesn't even seem to be an independent submodule. Once the work to split webthree-umbrella back into independ modules is complete, I'll take another look at applying the same changes to cpp-ethereum ethminer as I did to Genoil's.

[bobsummerwill]

The re-merger is complete, @nerdralph.

See http://github.com/ethereum/cpp-ethereum!

[come-maiz]

Hello!

I was testing the latest release of snapcraft using your project, and it builds nicely. I think this will help your investigation :)

#3541

I'll be around if you have questions, or need a hand.

pura vida.

[come-maiz]

alright! Thanks to @chriseth and @chfast a snap can now be built from master.

So now you are all ready to push to the store. I suggest to build one snap first, and push it to the edge channel, so you get to know what the store offers: https://snapcraft.io/docs/build-snaps/publish

Let me know if you need a hand. I'm also available in https://rocket.ubuntu.com/channel/snapcraft (which is also a snap, pretty cool) or #snappy in freenode.

[come-maiz]

Ping @chriseth @chfast: did you have a chance to look at the store? I can give you a hand to automate the delivery to the edge channel.

[chfast]

I'm more interested in distributing the project as single binary instead of this. But in case of snap, what is needed from our side? To register a snap store account?

[come-maiz]

Hello! I come with great news :D

We have just moved https://build.snapcraft.io/ to beta. So @chfast, what's required is just to log in there and tell it to build your project. It will take care of continuous delivery for you, so every time that you make a change on your master branch, a new revision will be pushed to an unstable channel in the store and made available to all the ubuntu users. Once you are ready to make a stable release, you just have to move it to the stable channel, and then it will appear in the ubuntu software center and it will automatically be updated for all the users that previously installed it.

[chfast]

This repo needs a snapcraft.yaml file, so that Snapcraft can make it buildable, installable, and runnable.

[come-maiz]

oh damn, I'm sorry @chfast. build.snapcraft.io only searches for the snapcraft.yaml and snap/snapcraft.yaml. You have it in dist/snap/snapcraft.yaml.
So, you could move the file or make a link.

If none of those sound good, there's always the option to use travis for continuous delivery:
https://snapcraft.io/docs/build-snaps/ci-integration#using-travis

[chfast]

No problem, I will move it.