Cross package maker. DEB/RPM generation or conversion. Derived from jordansissel/fpm.

āŒˆāŒ‹ āŽ‡ branch:  cross package maker

Update of "snap"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.


Artifact ID: 60cea6b749507da570befd82a2b88dfe6ebddcf7
Page Name:snap
Date: 2015-04-27 20:22:57
Original User: mario
Parent: b166d2828bbc7c0408dcc9a078f7dbd237eceb18

Ubuntu Snappy packages

Ubuntu .snap packages are basically container-ish .deb packages, meant for parallel installation, incremental updates, or something.

The outer shell of .snap packages is still a classic Debian 2.0 binary archive.

debian-binary      # "2.0\n"
_click-binary      # "0.4\n"

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 <>
 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ā€¦
- 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/
-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
  - 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.