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

[Colin Watson]

On Tue, Jul 09, 2013 at 09:23:23PM +0200, Matthias Klumpp wrote:
> So, can someone maybe summarize what the Ubuntu plans currently are?
> Switching to PackageKit, getting rid of the parts of Aptd which are
> covered in PK? Because otherwise, creating a Click backend for PK
> doesn't make that much sense, if Aptd would have to reimplement it
> anyway... (Then, using Aptd directly would be the faster-to-implement
> choice)

Right now I'm just trying to develop a prototype.  I don't much care
what we end up using; I expect that reimplementing will be significantly
quicker than arguing about it in advance, and in any case I have no
input into what the desktop guys choose to do with PK/aptdaemon.
However, experimenting with any of these makes it easier for me to make
the low-level code the right shape.

> Some OT note: Is there a specific reason why this thing is called
> Click? IMHO this is a very bad naming choice which constantly leads to
> confusin, as there are/were Klik, Glick, Glick2 and Klick, which had
> similar goals (only Glick still exists in form of Glick2).

I'm not a huge fan of it either, but the name predates my involvement
and I hate naming arguments sufficiently that - whatever.

> Some hint about the code (in PK clickpackage branches): Currently you
> have PackageKit spawning a Click helper which itself calls a click
> binary... It might make sense to implement the Click backend in C/C++
> rather than in Python. The native backends get much nicer error
> reporting, and the past has shown that they are also faster (might not
> apply to the click case, and might not be the primary goal, but
> still...). So, if the click backend "just" spawns some other tool and
> catches it's output, doing a C implementation might not be that hard.
> Of course, if you plan more complex stuff and like Python better, feel
> free to use it ;-)

Yep.  I prefer to stick with Python for now just for rapid prototyping
reasons, but no reason for that to be permanent.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]