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 _______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel
