4 ms·

16.04 is the latest long-term support, brought out last April. If you actually want the latest snapd, you are best with 16.10 or using xenial-proposed. Using `

by _joel 10y ago

16.04 is the latest long-term support, brought out last April. If you actually want the latest snapd, you are best with 16.10 or using xenial-proposed. Using `sudo snap install {thing}` definitely doesn't use the store. I just installed openstack command line tools on a headless box. https://github.com/openstack-snaps/snap-openstackclients https://github.com/openstack-snaps/snap-openstackclients To create a snap, you use snapcraft.. basically YAML specification. I don't know where you are getting your detail there.

jhasse 10y ago
> Using `sudo snap install {thing}` definitely doesn't use the store. I just installed openstack command line tools on a headless box. https://github.com/openstack-snaps/snap-openstackclients https://github.com/openstack-snaps/snap-openstackclients I don't mean the store GUI application, but Canonical's servers / repository. > To create a snap, you use snapcraft.. basically YAML specification. I don't know where you are getting your detail there. ATM you still have to run snapcraft on Ubuntu 16.04+. Source: http://snapcraft.io/docs/build-snaps/ http://snapcraft.io/docs/build-snaps/
- _joel 10y ago
  Ok, so as noted, the backend canonical servers are for easy of use. It's possible to use another service if one was inclined. Still don't see what's specific about vendor lockin. If you couldn't run your own service and change the default provider, then I could agree that it's vendor lock-in but it needs (currently) a ubuntu or docker to build the snaps. I still don't class that as vendor lock-in. It's just missing effort in terms of multi-distro support. Saying it's vendor lock-in throws up fairly draconian images in my head and that's far from the case.
  - jhasse 10y ago
    Well, if one really wanted to use a different store, they'd have to change hard-coded URLs in snapd's source code (for example `snap login`), set up all the stuff (which was only tested on Ubuntu) and then ship these new tools. I doubt that Canonical would let you keep the "snap" name by then ...
    - mhall119 10y ago
      Somebody who wants to setup their own store can send a pull request making the changes they need to snapd to make it easier to configure. Right now it's unclear if a "different store" would use the same data and protocol or would want to do something entirely different. In the end it's just a means of getting a .snap downloaded, so it can be as similar or different as the implementer wants.

by _joel 10y ago

jhasse 10y ago

> Using `sudo snap install {thing}` definitely doesn't use the store. I just installed openstack command line tools on a headless box. https://github.com/openstack-snaps/snap-openstackclients https://github.com/openstack-snaps/snap-openstackclients I don't mean the store GUI application, but Canonical's servers / repository. > To create a snap, you use snapcraft.. basically YAML specification. I don't know where you are getting your detail there. ATM you still have to run snapcraft on Ubuntu 16.04+. Source: http://snapcraft.io/docs/build-snaps/ http://snapcraft.io/docs/build-snaps/

_joel 10y ago
Ok, so as noted, the backend canonical servers are for easy of use. It's possible to use another service if one was inclined. Still don't see what's specific about vendor lockin. If you couldn't run your own service and change the default provider, then I could agree that it's vendor lock-in but it needs (currently) a ubuntu or docker to build the snaps. I still don't class that as vendor lock-in. It's just missing effort in terms of multi-distro support. Saying it's vendor lock-in throws up fairly draconian images in my head and that's far from the case.
- jhasse 10y ago
  Well, if one really wanted to use a different store, they'd have to change hard-coded URLs in snapd's source code (for example `snap login`), set up all the stuff (which was only tested on Ubuntu) and then ship these new tools. I doubt that Canonical would let you keep the "snap" name by then ...
  - mhall119 10y ago
    Somebody who wants to setup their own store can send a pull request making the changes they need to snapd to make it easier to configure. Right now it's unclear if a "different store" would use the same data and protocol or would want to do something entirely different. In the end it's just a means of getting a .snap downloaded, so it can be as similar or different as the implementer wants.