3 ms·

> There's no substitute for your package maintainer personally auditing and preparing the package for you. This is true, but it's not a feasible approach for s

> There's no substitute for your package maintainer personally auditing and preparing the package for you. This is true, but it's not a feasible approach for software like Slack, Spotify, and VSCode that gets updated /weekly/. These aren't packages like 'libgit' that you could validate once and leave the same until you ship the next OS release. Some of these apps completely stop working if you fall behind by too many versions. Having people running older versions is also a huge pain in the ass as a developer, because those users inevitably email support, complain online about how the product is bad, etc. and only after lots of emailing does it turn out they're using a year-old version. (Full disclosure: I maintain Mailspring and switched to Snapcraft /very/ enthusiastically to have an auto-update mechanism that works across linux distros!)

flukus 8y ago
> This is true, but it's not a feasible approach for software like Slack, Spotify, and VSCode that gets updated /weekly/. These aren't packages like 'libgit' that you could validate once and leave the same until you ship the next OS release Package managers don't prevent this at all. If you host the repository then you can update as often as you'd like. Some whole distros (arch) do just this.
- evand 8y ago
  You can update as often as you like, but that does not ensure users will get that update, nor does traditional packaging make it safe to install the update (no rollbacks, maintainer scripts run as root and have full access to the filesystem, library mismatches, etc). I'm all for debs and rpms, but they seem best suited to providing the base system. [disclaimer: I'm on the Snapcraft team]