Thanks, Leo. Do you already have snaps for similar programs (e.g. screen, tmux, ssh)? Mosh is probably going to have similar needs to those re: the isolation or "plugs".
Generally we add new platforms/distros when somebody submits a PR or volunteers to be a maintainer; my suggestion is for you to just submit a PR with a proposed snapcraft.yaml (and changes to .travis.yml if appropriate) and we can all try it out. Cheers, Keith On Fri, Jan 13, 2017 at 7:56 AM, Leo Arias <y...@elopio.net> wrote: > 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
