[mosh-devel] snap package for mosh

[Leo Arias]

On Thu, Jan 12, 2017 at 11:59:53PM -0800, Keith Winstein wrote:
> Right now we have a Debian package, which we maintain in our own source
> tree, and which we upload to Debian every time there's a new release. That
> flows into Ubuntu as part of the normal release schedule. For users who
> want something more immediate, we also have the mosh-dev PPA that pulls
> from our GitHub repository once a day and auto-builds the Ubuntu source and
> binary packages, and then we have a "stable" mosh PPA as well, which only
> gets updated on new releases.

That is great because we would love to hear your impressions, taking into
account your experience with debs and PPAs.

In classic Ubuntu you have to follow our 2 years/6 months release cycle, or use
a PPA. When you release a deb to an LTS, you will quickly get many users in an
outdated version for many years, you need maintainers to review your package to
make sure it's compatible with the archive, and you need to follow a
heavy-weight format full of conventions and rules to make the archive
consistent. debs are great for some projects and some users, and we are using
them as a base for our new Ubuntu Core distro; but something like getting the
mosh 1.3.0 to xenial, or even to trusty, it's a huge pain.

That's what we are trying to improve with this new dev experience. Snaps are
mounted read-only directly from the uncompressed package and they bundle all
their dependencies. So there is no conflict between snaps, nor with the base
system, and then we can get out of your way, you don't need the distro as a
middle man and you can just push to the store any version you want, any time
you want.

Snaps are also isolated to their sandbox for security reasons. But there's
where things get interesting with mosh...

> Is it possible to teach Launchpad to also auto-build a snap once a day (if
> our Git repo has changed), alongside the PPA .debs? Can we script Travis-CI
> to automatically build and push a snap each time it runs a successful CI
> test on the master branch? Or how would you recommend we do this?

Yes, we want the snapcraft.yaml metadata to be as simple as possible, and to
use continuous deployment, so you will just have to spend a little time
packaging one time, and then everything is automatic. You can take a look here:
http://snapcraft.io/docs/build-snaps/ci-integration

> Mosh is pretty simple so I doubt we're going to be pushing the boundaries
> of the snap format -- it's basically two unprivileged binaries and some man
> pages. And a bash-completion script that gets put
> in /usr/share/bash-completion/completions/mosh. I guess that might be a
> little more interesting, depending on whether snap can handle that.

If I understand correctly, the mosh server is a terminal emulator. (I'm not
sure about mosh internals, so I'm eager to understand more about that too :)
By default, snaps can't do anything outside of their confinement, so things
like calling binaries they don't provide or accessing devices will be blocked.
And that's good enough for the vast majority of applications out there, they
just declare a few "plugs", like listening to the network, and they can fully
function. But now we are turning our eyes to also support developer tools, like
emacs which needs to be able to read and write to /etc, or a shell like zsh, or
mosh.
They pose a bigger security risk than normal apps, but still we think it should
be a direct agreement between the user and the developers distributing that
package. So you would declare on your snap the kind of things that your
application will do out of its confinement, and the user decides to grant that
permission or not.

> Happy to work with you on this if you think there is user demand for it.

Well, I'm sure it will make it easier for you to do early testing of the new
release, and once you are ready to release to the stable channel, many of your
users on current Ubuntu versions will find the update in the store and make the
jump.

But as I said above, we are trying to make it extremely lightweight, so it
shouldn't take a lot of your time. Developers usually just start by dumping an
existing binary into the snap, and use the devmode confinement to get a list of
the security exceptions that they need. Then if you like, you can build the
binary during the snapcraft packaging, which will make it easier to provide the
snap for other architectures.

I'm about to leave for vacations, so I encourage you to take a look at
http://snapcraft.io/create/ and give it a quick try. Then when I return the
following week I would be happy to answer any of your questions, and give you a
hand with the packaging if you need it.

I'm sorry for the long email, but I'm excited about snaps and mosh, and really
eager to hear your comments :)

pura vida