[packagekit] Improved pkt tool

Richard Hughes hughsient at gmail.com
Fri Sep 7 07:36:10 PDT 2007


On Fri, 2007-09-07 at 16:26 +0200, Tom Parker wrote:
> Richard Hughes wrote:
> > Have you seen pkcon and pkmon in /client? How does pkt compare to pkcon?
> 
> I'd vaguely noticed them at some point in the past, but I've just had 
> another look. Couple of points
> 1) From the POV of the CLI, it's close to the interface I want 
> eventually, except with wanting to be able to specify just a package 
> name not a package_id for install (and letting it pick a version for me)

Sure, specifying a package_id sucks. pkcon needs to do the search, pick
the (only?) best package_id and then install that.

> 2) It doesn't catch certain classes of error e.g. if PackageKit isn't 
> running, it just plain dies with no explanation (unless you've noticed 
> the "verbose" option and then you get the informative "The name 
> org.freedesktop.PackageKit was not provided by any .service files"). On 
> the one hand, this might just be an artifact of my current setup (no 
> installed dbus files for PackageKit, and running it in a separate 
> terminal when testing).

That's because you are not using dbus service activation. If you have
that installed correctly (new enough dbus?) it will autostart the
daemon.

>  OTOH, this allows noting that this means that 
> the current libpackagekit API doesn't provide any options AFAIK for 
> catching errors in C clients.

Yes, we need to add this. I believe it's already in the TODO file.

> 3) It's pretty complicated for a simple client, and looks like overkill 
> for most cases of someone wanting an easy introduction to PackageKit.

Well, I prefer the c option (obviously) but I've got no problem with an
alternative tool in tools/ for developers.

> I'm voting for the "include both" option.

If you mean include then just go ahead and commit it to tools. If you
mean "install by default" then we need to argue some more :-)

Richard.





More information about the PackageKit mailing list