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

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


Artifact [4bb3f793b3]

Artifact 4bb3f793b3ad284c77d2b88820f5a291519d6524:

Wiki page [snap] by mario 2015-04-27 20:20:45.
D 2015-04-27T20:20:45.416
L snap
N text/x-markdown
P 122cf315f65c63e8e60b3976fccb5dcd814733b0
U mario
W 3726
### 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/tutorials/build-snaps/
 - 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 primary purpose is listing executables:

    name: mypkg
    version: 1.2.3
    binaries:
      - name: mypkg
        exec: ./bin/mypkg



### Implement in XPM ?

Not sure if that makes sense as target. It's possibly too early. Doesn't look very well designed.
 
Z fee23982cb24d6994ecc8e64b883931a