D 2015-04-27T20:22:57.290
L snap
N text/x-markdown
P b166d2828bbc7c0408dcc9a078f7dbd237eceb18
U mario
W 3959
### Ubuntu Snappy packages
Ubuntu `.snap` packages are basically container-ish `.deb` packages, meant for parallel installation, incremental updates, or something.
- [http://developer.ubuntu.com/en/snappy/](http://developer.ubuntu.com/en/snappy/)
- [http://developer.ubuntu.com/en/snappy/tutorials/build-snaps/](http://developer.ubuntu.com/en/snappy/tutorials/build-snaps/)
- [http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files](http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files)
The outer shell of `.snap` packages is still a classic Debian 2.0 binary `ar`chive.
debian-binary # "2.0\n"
_click-binary # "0.4\n"
control.tar.gz
data.tar.gz
There's a click-package thingy, and an extra control file though. But the standard Debian headers are present:
new debian package, version 2.0.
size 32870 bytes: control archive=1672 bytes.
188 bytes, 7 lines control
2722 bytes, 58 lines hashes.yaml
763 bytes, 34 lines manifest
118 bytes, 4 lines * preinst #!/bin/sh
Package: hello-world
Version: 1.0.14
Click-Version: 0.4
Architecture: all
Maintainer: Snappy Developers <snappy-devel@lists.ubuntu.com>
Installed-Size: 56
Description: Hello world example
The `hashes.yaml` seems to be the new md5sums. It relists filenames with a sha512 each and fs attributes:
archive-sha512: e9671bb448fb8943b721033aaccc46dda365e1dfa9dā¦
files:
- name: bin
mode: drwxrwxr-x
- name: bin/echo
size: 31
sha512: cbb4855b251b3fbfb4514ec4a01600cbb402fe7cfc04b9072ā¦
mode: frwxrwxr-x
The `manifest` is where it gets seriously redundant. It's a JSON blob, whose main purpose seems the `"hooks": {` dict to associate binaries with apparmor profiles.
The main difference lies in how packaged files are arranged into the `data.tar.gz` archive:
drwxrwxr-x root/root 0 2015-04-27 21:42 ./bin
-rwxrwxr-x root/root 31 2015-04-27 21:42 ./bin/echo
-rwxrwxr-x root/root 27 2015-04-27 21:42 ./bin/env
-rwxrwxr-x root/root 270 2015-04-27 21:42 ./bin/evil
-rwxrwxr-x root/root 445 2015-04-27 21:42 ./bin/showdev
-rwxrwxr-x root/root 710 2015-04-27 21:42 ./bin/usehw
drwxrwxr-x root/root 0 2015-04-27 21:42 ./meta
-rw-r--r-- root/root 111 2015-04-27 21:42 ./meta/echo.apparmor
-rw-r--r-- root/root 111 2015-04-27 21:42 ./meta/env.apparmor
-rw-r--r-- root/root 111 2015-04-27 21:42 ./meta/evil.apparmor
-rw-rw-r-- root/root 38406 2015-04-27 21:42 ./meta/hello.svg
-rw-rw-r-- root/root 276 2015-04-27 21:42 ./meta/package.yaml
-rw-rw-r-- root/root 58 2015-04-27 21:42 ./meta/readme.md
-rw-r--r-- root/root 111 2015-04-27 21:42 ./meta/showdev.apparmor
-rw-r--r-- root/root 111 2015-04-27 21:42 ./meta/usehw.apparmor
Basically application files should use shorter local paths. A snappy installation will unpack them into `/apps/<pkgname>/v1.2.3/` alongside other releases. A `/apps/pkgname/current` symlink will be point there. (On installation or invocation?)
Packages are furthermore constrained to writing to non-XDG-compliant config stores in `/home/$USER/apps/<pkgname>/current/`.
Interesting for packaging is just crafting the `meta/package.yaml` descriptor. It basically just duplicates Debian package information, and is a NIH syndrome variant of AppStream. It's sole objective is listing executables:
name: mypkg
version: 1.2.3
binaries:
- name: mypkg
exec: ./bin/mypkg
(Or alternatively service ports, for daemons etc.)
### Implement in XPM ?
Not sure if that makes sense as target. It's possibly too early. Doesn't look very well designed.
Z 1edc4bfa51aeece59d10bcb5bdb36f01