[packagekit] [Ubuntu-appstore-developers] D-Bus API for Click Packages (PackageKit/AptDaemon)

[Sebastian Heinlein]

Am Mittwoch, den 03.07.2013, 14:11 +0100 schrieb Colin Watson:

> > AFAIK the required API of the AppStore would be quite small and the
> > package downloading and update calculation is done in the GUI component,
> > right? So we could end up with a very small set of methods e.g.
> > InstallFile() RemovePackages(), GetPackages(FILTER_INSTALLED)?
> 
> 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.

I just wrote a small click backend for PackageKit as a proof of concept.
You can find the patch attached to this mail.

> There are some complexities relating to per-user installation of
> packages, which is a requirement: that is, all packages will be unpacked
> as a privileged user, but it's possible to unpack multiple parallel
> versions of a package and each user will be able to register their own
> "current version" links.  Do you have any thoughts on whether this kind
> of dual operation (unpack as privileged user, link as ordinary user)
> should be done as two D-Bus methods or one?

> I was indeed looking at aptdaemon for this.  As an alternative to
> replacing the whole worker, do you think it might make sense to modify
> apt.debfile.DebPackage.install to understand click packages (a rather
> small change, at least if it only handles the privileged side of
> things)?  Since they use the .deb container format, that seems like a
> convenient class to reuse.  Part of the point of using the same
> container format was to reduce the amount of work we needed to do at
> this kind of layer, for code that's fundamentally not that interesting.

Replacing the "whole" worker isn't very intrusive. That is already done
by the PackageKit compat mode :)

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.

So after the 1.1 release of aptdaemon. I could refactor the workers a
little bit to remove the dependency of python-apt.

> > Furthermore it limits the click package implementation to Python or
> > requires a Python library to access the click packages system.
> 
> 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? How to handle errors of the click command?

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

> > The support for the latest PackageKit 0.8 system D-Bus interface landed
> > in aptdaemon's trunk today. I plan to release and upload a 1.1 version
> > of aptdaemon soon. This will unblock the transition to packagekit 0.8.9
> > for saucy.
> 
> That would be great, and let me know if I can help with that.  I'm
> really agnostic as to whether we use aptdaemon or PackageKit as the
> backend; I think it definitely makes sense to use one of them rather
> than inventing some new service, but I wanted to avoid getting caught up
> in the PackageKit transition [...]

I fixed some bugs recently and the 1.1 of aptdaemon with the PK 0.8 API
gets into shape.

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

Cheers,

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-click-Add-a-very-basic-click-package-backend.patch
Type: text/x-patch
Size: 13363 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20130706/3fb6c2c2/attachment.bin>