Monday, 13 May 2013

Re: App installer design: click packages

On Fri, May 10, 2013 at 11:45:37AM +0100, Matthew Paul Thomas wrote:
> Colin Watson wrote on 08/05/13 11:14:
> > So, at Steve Langasek's request, I've been putting together a
> > proof of concept of a low-level app package installer and
> > packaging format. Highlights of what it can do so far are:
> >
> > ...
> >
> > * installs each app to an entirely separate directory
> >
> > * entirely declarative: maintainer scripts are forbidden
> Do these two entail that an installation/update/removal can be
> interrupted at any point without corrupting the system?


> This is, as I understand it, a long-standing problem with deb/dpkg. A
> PC has a power outage or a kernel panic while a package is installing
> or updating, and the packaged software becomes unusable, and possibly
> stymies future package operations too.

Well, people have derived this kind of idea from observing the behaviour
of the whole system rather than from knowledge of the specific software
components involved, and so the notion of where problems lie tends to
get misattributed. dpkg itself always leaves things in a known and
valid state (in its terms; that is, there's a defined next step you can
take to repair things where necessary). The problem is that layers
above dpkg are not very good at coping with some of the valid states
dpkg leaves things in, and can end up requiring manual intervention as a

This won't be a problem here. At least to start with, we'll be
unpacking each version of each package into its own directory, and
atomically flipping a symlink at the end. An incomplete unpack won't
affect the previously-installed version of the package, and there's no
possibility of affecting future package installations since there is no
shared package database.

> > * indexing support and other frontend things (i.e. the app store)
> That will affect the package format. For example, each package
> providing metadata in multiple languages.


> > Is there anything else people can think of that a system like this
> > needs to consider?
> A system that aims for an order of magnitude more applications, than
> Debian or Ubuntu has packages, should not rely on every package having
> a unique name. For example, a package should not determine the name of
> the installation directory itself.

In an entirely flat namespace this is a problem. The current plan is to
use reverse-network-domain names, e.g. com.ubuntu.apps.calculator or
org.wikipedia. This is the same scheme used in the Android Market, and
I think is adequate protection against this class of problem.

I considered using UUIDs or similar, but those have the annoying
property that it's difficult to look at a bit of the filesystem
hierarchy and know what it means without looking inside it and guessing
(a property I've always hated when trying to work out what's wrong with
some bits of Windows systems); this is less relevant on phones/tablets
but will matter later for convergence.

> Finally (and most bikesheddingly), a system initially aimed at phones
> and tablets should not be named after something you do with a mouse.

I fear the name predates my involvement. Perhaps Stuart can comment.

Colin Watson [[email protected]]

ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: