ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-07-11 10:40 AM, 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 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.

Do we know where this is going to be defined in the manifest file yet?

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

That should be $(click package)_$(desktop file)_$(version)

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

So, how is unity going to obtain the "Application ID"?

Marc.