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. -- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
