ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Thu, Jul 11, 2013 at 09:40:30AM -0500, Ted Gould wrote:
> 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-package.readthedocs.org has some of this (you reference the
corresponding source).

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

Yes.

> 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)/

You must not rely on this directory.  It may change, particularly to
support things like non-removable preinstalled apps in the system
partition, or other cases of OEM apps.

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

Yes.

> 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.

Yes.  (Note that the complexity arising from this of needing a composite
app-id/application/version identifier also arises from having multiple
parallel-installed versions; we could only avoid the composite
identifier if we eliminated both requirements.)

> 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).

Yes.

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

Yes.

> 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.

This is plausible, but system vs. user hooks aren't fully defined yet.

> 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.

Yes.

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

I would like to make this as declarative as possible, along the lines of
the efforts I've made in the current hooks spec to avoid being
error-prone; I hope that it will amount to "remove the file pattern
named in the hook, and run the named update program if applicable to
catch up with any changes", but we'll see.  This should settle down this
month once I have a chance to play with some real-world examples.

> 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.

Yes.  (Current implementation, deliberately as simple as possible:
/opt/click.ubuntu.com/.click/users/$user/$app_id is a link to the
version of $app_id installed for $user.)

> 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).

I think you're first to lay it out so explicitly, but seems plausible.

> 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.

Sounds right.

> 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.

I agree that this is a good idea.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]