ubuntu-appstore-developers team mailing list archive

[Ted Gould <ted@xxxxxxxxxxxxx>]

Same e-mail, hopefully revised based on everyone's feedback.  I think
there are still some install directory issues to work out for the
security profiles, but I'm going to ignore that one for now.

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 accessible by asking the click packaging system.

Every click package will contain a manifest that is the root of
information about that package.  It is in JSON and located in the
package directory under .click/info/$(package name)/manifest.

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.

Note: Hooks aren't fully defined yet, but it's likely the following
points are true.

Upon installation of the package there will be a set of hooks run.  All
hooks will be defined in the system, the package will not be able to
provide hook scripts.  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


No one should have anything left to say now, right?  ;-)

Ted

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