ubuntu-appstore-developers team mailing list archive

[Matthias Klumpp <matthias@xxxxxxxxxxxx>]

2013/7/9 Sebastian Heinlein <devel@xxxxxxxxxx>:
> Hello Colin,
>
> You could use the data field of the PackageKit package id [1] to
> separate calls to the click package system and the APT system. This
> would make it possible to use the click packages also on APT based
> systems if aptdaemon is used.
>
> E.g. the method call RemovePackages(["myapp;1.0;armhf;CLICK"]) would
> remove the click package myapp and
> RemovePackages(["myapp;1.0;armhf;local") the local Debian package.
This is definitely a good solution, Listaller does exactly the same.
But it also encodes the package origin (remote or local source) within
the data.

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)

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). While
talking about these things, I constantly refer to Ubuntu's solution as
"Ubuntu's solution", because using the Click name currently leads to
confusion (this might change, in future....). Also, since this thing
is mainly targetted at mobile devices, wouldn't "Touch" be more
fitting? ;-)

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 ;-)

Cheers,
    Matthias