ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Sat, Jul 06, 2013 at 10:50:17PM +0200, Sebastian Heinlein wrote:
> Am Mittwoch, den 03.07.2013, 14:11 +0100 schrieb Colin Watson:
> > I believe so, at least as a first pass.  These would roughly map to
> > "click install", "click remove", and (forthcoming) "click list".
> 
> The native Aptdaemon D-Bus interface doesn't support querying the
> package cache. It was designed for a sophisticated client application
> that accesses the cache directly and only makes use of the daemon for
> the higher privileged manipulations of the cache.
> 
> So if you want to have a click list method I would suggest using the
> PackageKit interface. Independently of the question if the interface is
> provided by aptdaemon or packagekit.

OK, agreed.  It's sounding like using PK directly is the easier path.

> Why would you need the debfile.DebPackage class at all? Since you don't
> have got any dependency information you could call the click command
> directly, right? The DebPackage is used to calculate the dependencies
> that need to be installed from the archive. The DebPackage class would
> only be interesting if the click-package command uses a status fd as
> dpkg/apt do.

It doesn't, so sounds like we can mostly get away without that.  I
hadn't realised DebPackage was only used for dependency calculation.

However, at some point we will want to fetch the Installed-Size field
from the package's control metadata so that we can check for adequate
disk space up-front.  We can live without that in the first pass, and
perhaps that would be better as a defined exit status from "click
install" anyway.

> > Not really.  It would make sense to invoke /usr/bin/click as a
> > subprocess, which the relevant parts of aptdaemon can already do without
> > much difficulty, and as mentioned above we can reuse existing Python
> > libraries for things like handling some metadata.  But it depends how
> > much sophistication you think aptdaemon would need.
> 
> How much sophistication does the design team need? E.g. progress and
> status reporting?

I checked a while back and confirmed that we don't need these.

> How to handle errors of the click command?

The recovery path from any error is just to repeat the command (it never
gets into stuck states that require the equivalent of "dpkg --configure
-a" or anything, although you might run out of disk space), so just
passing them up naïvely as failures should be fine.

> > > On the other hand there is the PackageKit daemon and its D-Bus API. The
> > > PackageKit daemon allows to write backends in different languages: the
> > > current Python based click package system could use a spawned backend.
> > > If it is still the plan, click packages could be re-written in C/C++
> > > later without having to do any changes on the communication between the
> > > daemon and the client.
> > 
> > I'm not sure I understand how this isn't already the case with
> > aptdaemon.  Can you elaborate?
> 
> If you re-write a PackageKit backend the daemon-client-communication
> will be the same. You don't have to re-implement the whole communication
> in another language - only the backend.

OK, but aptdaemon can (and IMO should, if it gains support for Click
packages) also call "click" as a subprocess rather than via its Python
interface.  It doesn't *have* to care about click's implementation
language unless it deliberately chooses to.

> > > PackageKit provides two D-Bus interfaces to manage software. The system
> > > D-Bus interface should be used by the native client libraries. For
> > > applications that cannot access the client libraries or don't want to
> > > provide a separate graphical user interface that handles errors or shows
> > > the progress there is also a small session D-Bus interface which is
> > > implemented by gnome-packagekit and apper.
> > 
> > Do we need to use a session interface for the kinds of per-user work I
> > described?
> 
> You could mis/re-use the InstallPackages transaction type to set the
> link to the version of the package that the user wants to use.

I was thinking more about whether operations that were sensitive to the
calling user ID needed to be on the session bus.  It doesn't seem so,
though; it looks like I can use pk_backend_job_get_uid.

> Subject: [PATCH] click: Add a very basic click package backend

Thank you very much again for putting this together.  It's always easier
to talk about example code rather than ideas for code ...

As I said in a previous mail, I don't think this should go on master yet
since too much is still subject to change, but perhaps you could put it
in a published git branch somewhere so that we have a convenient place
to work?  I plan to make some fairly substantial revisions to this in
tandem with my work on per-user package installation in click itself.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]