[packagekit] A PackageKit browser plugin

[Owen Taylor]

On Sun, 2008-07-27 at 09:00 +0100, Richard Hughes wrote:
> On Thu, 2008-07-24 at 14:39 -0400, Owen Taylor wrote:
> > What do people think...
> 
> I think it looks great. Some comments tho:
> 
> * You are using gpk-install-package-name -- you probably don't want to
> call the binary name, you want to call the InstallPackageName DBUS
> method -- see http://www.packagekit.org/pk-faq.html#session-methods for
> more info.

OK, I'll look at switching it over.

I actually would like something a little different ... since it isn't
100% clear that clicking somewhere on a web page is going to install a
package on your system directly (possibly taking quite some time to
download, possibly keeping you from suspending, etc.) I'd really prefer
to always show a confirmation dialog like the one you get when there
are additional dependencies to install. It would be nice if that was
an option through the D-BUS interface.

I could obviously pop up a dialog myself but:

 A) Wouldn't have the download size
 B) Would suck if there was then also going to be the additional
    dependencies dialog
 C) Some hopes of making the plugin GTK+ independent

> * You are using the libpackagekit Resolve() -- which is fine, but you're
> using the status boolean to check for installed. It's perfectly valid
> for PackageKit to emit installed foo-0.1.2, available foo-0.1.3 if there
> is a package update available. Maybe one to check for.

I'm not sure I understand this comment ...  do you mean the 

enum PackageStatus { IN_PROGRESS, INSTALLED, AVAILABLE, UNAVAILABLE, INSTALLING };

Enumeration? Actually despite this enum, the code does handle INSTALLED
and also available for upgrade, since it has separate "availablePackage"
and "availableVersion" fields, but it probably would be clearer with
a UPGRADABLE status.

What I don't do at the moment is show a user interface for that case..
it just look like the INSTALLLED case. I'm not completely sure that
handling it is necessary... basically if the user hits that dialog
more than infrequently, then the right user interface is
"Fix automatic updates on your system!". But certainly you could imagine
cases where it might be hit for newly released packages. My main
reason for avoiding it was that having multiple links made the UI
code considerably trickier :-)

I'll take a look at a "_Run 1.2.1 now_. _Upgrade to version 1.2.3_" 
user interface.

> * The destop file checking code is already present in gpk-client-run.c
> -- maybe we can share some code there.
> 
> > does this make sense as part of the PackageKit project?
> 
> Yes, but the licence could be tricky. All of stuff in PackageKit has to
> be (L)GPLv2+ -- I can't confess to being a licence expert, so I don't
> know how MPL 1.1/GPL 2.0/LGPL 2.1 would affect things.

If you read the details of the license it's actually MPL 1.1/GPL 2.0 or
greater/LGPL 2.1 or greater. So stripping down to any GPL or LGPL
variety is feasible. I was just keeping things simple by sticking to the
tri-license license of the Mozilla stub code.

In fact the Mozilla stub code could be eliminated with moderate work if
there was a desire to change the license to something oddball or move
the codebase from C++ to C. 

- Owen