native-packages 0.10.0

0.10.0 lets AppImages update themselves. A Linux target can now embed update information and publish a .zsync file beside its AppImage, so AppImageUpdate, AppImageLauncher, AM, Gear Lever and apps with their own updater can find the next release and download only what changed.

New

• AppImages that know where their updates are. Give an AppImage target an appimage.update_information, such as gh-releases-zsync|owner|app|latest|app-*-x86_64.AppImage.zsync. The string goes into the AppImage runtime's update section, and the build writes NAME-VERSION-ARCH.AppImage.zsync beside the AppImage with zsyncmake. build.json records both files and publish --to github attaches both. The same inputs still give the same bytes. By @crmne.
• A wrong update string fails before the release. Validation checks that a GitHub string names release.repository and that its pattern matches the target's own .zsync file, so an AppImage never ships pointing at a file that is not there. After the build, the string is read back from the AppImage and the .zsync file is checked against the AppImage's name, length and SHA-1. By @crmne.

linux-amd64:
  platform: linux
  arch: amd64
  libc: glibc
  formats: [appimage]
  appimage:
    update_information: gh-releases-zsync|owner|app|latest|app-*-x86_64.AppImage.zsync

The reusable packaging workflow installs zsync. To build locally, install it from your distribution (zsync on Debian, Ubuntu, Fedora and Arch). Read Update information for both accepted forms.

Known limitations

• The AppImage is still not signed.
• With the latest tag, updaters follow the newest stable GitHub release, so prereleases are not offered as updates.
• Each architecture needs its own target and pattern. An after_package hook must leave the AppImage unchanged, or the build fails because the .zsync file no longer describes it.

Thanks

Thanks to Spotifast, whose AppImage self-update (crmne/spotifast#737) needed this.

Full changelog: v0.9.0...v0.10.0