Click packages

Registered by Colin Watson

Next steps for the click-package prototype for simplified app package installation:

Blueprint information

Steve Langasek
Colin Watson
Colin Watson
Series goal:
Accepted for saucy
Milestone target:
Started by
Colin Watson
Completed by
Colin Watson

Related branches



== Mission statement ==
click-package is a simple way to package simple apps and is not designed to replace .debs

Thread "App installer design: click packages" on ubuntu-devel mailing list discussed the initial prototype for this plan:

We want to avoid a situation which no longer encourages GPL compliant packaging, i.e. we want to encourage people to include their source. How is this going to work? Apple had this issue as they had no source, and then could not be GPL compliant. For QML apps the binary is the source, and certainly the point here is to allow binary only apps where needed. Potentially we could offer links to the source, but this is not going to work well with the ubuntu archive view of the legal issues. We could include the src with the binaries, but that is going to make the binaries rather larger; not very appropriate for the phone.

We are expecting these click packages to be usable on the desktop at some point in the future. It may not be in the exactly the same form by then. We are trying to target a very small subset of applications here, we are not trying to replace .deb packaging with this new format as that will just mean we end up with all the same problems and complexity and lose any simplicity advantage to the entry level developer would be lost.

- When using the Ubuntu SDK you would expect the base system to include the dependencies you need.
- any dependancies you do need you will include, though most libraries are not amenable to this usage

Security will be supplied for such packages via app containment. This allows us to take binary only packages.

As we are aiming for a 100K 200K 1M apps in the store world, we cannot look to have a local list of packages. That is just not going to scale. Thus if we do integrate this with apt-daemon we cannot expect to have a complete list, partial lists from searches etc may well make sense. (This is new packages rather than installed packages.) We also need to track installed packages. We will want to track which packages were installed for which users. We also need this to work out which ones have changed.

A strong desire for using aptdaemon is that it provides a well known API, one which we already have to use for .deb packages and therefore something we already have integration for. Particularly as this would allow use of packagekit apis.

We need to put together a specification on the layout of the click package should there be any requirements. For example open source packages may require copyrights. A changelog may be handy but should not be mandatory. Trying to keep this minimal to maintain the overall goal of simplicity.

Tests, is there some way we can put any tests in the package or in the source or similar, so that we could do something like CI on your packages. Right now there is nothing planned to allow this to occur centrally so it is beyond this 1.0 level. This could be revisited later.

Installation and removal will be done as a speciailised non-root user, but NOT the user under whom it will run. This helps to avoid application modification and to avoid some escalations. Runtime containment via independent users, apparmor, namespaces and the like:

We are expecting to have to do some cross compiling of apps, whether that will occur on the client or the server is currently unclear. Some things are not easy to cross compile at all. If you are using the SDK you should not have to think about this too much. This is likely an 'after 1.0'.

Discussion points

 * how could we ship source packages
 * The primary target is phones/tablets (is that right?)
  * Well, for now. This may eventually land on the desktop as well.
 * Click-packages are for "leaf" packages only, even on the desktop.
 * How many apps would be QML only (and therefore already include the source), and how many would need an additional mechanism for the source?
 * Will we repackage existing apps as click-packages? Maybe, maybe not.
 * Who will handle the database of installed click-packages?


Work Items

Work items for ubuntu-13.06:
[cjwatson] talk with Zoltán about qtcreator integration: DONE
[cjwatson] Finalise format version 0.1 and upload polished prototype to saucy: DONE

Work items for ubuntu-13.07:
[cjwatson] "click list" interface to print list of installed apps: DONE
[cjwatson] Design and implement D-Bus API, either directly or by extending packagekit/aptdaemon/similar: DONE
[sbeattie] Write apparmor confinement hook (security-s-appisolation-sdk): DONE
[sergiusens] Figure out how to add click packages to touch images: DONE
[cjwatson] Support per-user package installation/registration: DONE
[cjwatson] Sort out integration of desktop files: DONE
[sergiusens] Update click packages to 0.2 specification: DONE

Work items for ubuntu-13.08:
[cjwatson] Add installed-size and icon information to "click list --manifest": DONE

Work items for ubuntu-13.09:
[cjwatson] Support fat packages: DONE
[cjwatson] Support multiple installation root directories so that some apps can be "system" and some "user": DONE
[sergiusens] change logic to install click packages on boot instead of during image build: DONE

Work items for ubuntu-13.10:
[cjwatson] Support signed packages: INPROGRESS
Add support for separated debug symbols: TODO

Work items:
figure out how to upload and serve the source for packages: TODO
document the REST API ( DONE
[beuno] define a specification for click package content for any required bits (such as copyrights for GPL): TODO
[sil] talk to Roberto about client work items: DONE
Support package deltas: TODO
Consider arrangements for shared data files among packages: TODO

Dependency tree

* Blueprints in grey have been implemented.