ubuntu-appstore-developers team mailing list archive

[Ted Gould <ted@xxxxxxxxxxxxx>]

I hesitate to call these requirements, because I don't feel I the
authority to declare them that, but I wanted to write down my
understanding of things to give people a chance to object.  If no one
objects, I guess this is canon.

Click Basic Points

A click package can be identified with a reverse domain name that
represents the project: com.ubuntu.foo

A click package will have a version number defined, and will be
installed in a separate directory based on the version number.  This
directory will be /opt/click.ubuntu.com/$(package)/$(version)/

Every click package will contain a manifest that is the root of
information about that package.  It is in JSON and called manifest.json.

A click package may have (and won't in v1) several applications
available from that package.  Each of those are defined in the manifest
with one being designated as "primary" for showing to the user
removal/installation graphics.

Each application in the package will be represented by a file that
conforms to the Freedesktop.org Desktop file format that contains
information on the icon and executable path.  The core difference being
that it'll have relative paths that aren't resolvable using standard XDG
directory definitions (they'll all be in the package).

Each application defined in the manifest will also have a security
definition in the manifest.

Upon installation of the package there will be a set of hooks run.
There are two types of hooks, system hooks and user hooks.  An example
of a system hook would be one that builds the apparmor profile and
installs it.  An example of a user hook would be one that takes the
desktop file template and puts it in ~/.local/share/applications with
paths that can be resolved to the user selected installed version of the
app.

When I user installs an application version that was already installed
by another user, the user hooks will be run in that user's account.

All user and system hooks will provide a way to clean up the system/user
account on uninstall of the version.

The Click packaging system will maintain a reference count for which
user installed which version of a particular package.  It will also
garbage collect when no user has that version of the application
installed.

The graphical installer will query the Click packaging system to
determine disk space cost of installing a new application or version.
For instance, if it's just an upgrade on a single user system space used
would be: sizeof(new) - sizeof(old).  But if there is another user that
has the same version it is: sizeof(new).  If it's upgrading to a version
already installed by another user and this user is the last user for the
selected version it is: -1 * sizeof(old).

When the security hook runs it will create an AppArmor profile of the
name $(click package)_$(application)_$(version) that the application
should be confined with.

The same pattern as above should be consider the "Application ID" for
all usage throughout the system.  Including identifying the application
to Mir/HUD/etc.

References

http://bazaar.launchpad.net/~click-hackers/click/trunk/view/head:/doc/file-format.rst
https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

I think that's it.  Thoughts?
Ted

Attachment: signature.asc
Description: This is a digitally signed message part