[packagekit] Anjuta and PackageKit

[James Antill]

On Wed, 2008-10-29 at 08:41 +0000, Richard Hughes wrote:
> On Wed, 2008-10-29 at 11:47 +0530, Debarshi Ray wrote:
> > The problem is that when a user wants to create a new project using
> > Anjuta he gets some options. eg., Gtk project, Gtkmm project, PyGtk
> > project, simple C/C++ project, X project, etc.. If the user wants to
> > start a Gtkmm project and does not have the necessary -devel or -dev
> > packages, things do not work [1]. I also do not want to take the
> > extreme stand of having Anjuta have all these libraries and headers in
> > its dependency chain. That will simply bloat the dependency chain and
> > waste bandwidth and space.
> 
> Right, this is exactly the sort of thing that you should use PackageKit
> for. At the moment projects like Abiword want to make PackageKit
> download dictionaries of the correct language, without depending on all
> locales.

 I completely agree, from what I understood this was the problem that
PackageKit was trying to solve: allowing upstream access to APIs they
can use to solve the install/update problem without having to write N
versions for each distro. ... or do something themselves like firefox
etc.

> > Right now, I am only the Fedora packager of Anjuta and a few of its
> > dependencies. So where should I start if I were to work on something
> > like this.
> 
> Well, you've got an initial big choice:
> 
> * session helper
> * system core
> 
> The first gives you a nice fire and forget interface like
> 
> /* execute sync method */
> ret = dbus_g_proxy_call (proxy, "InstallPackageName", &error,
> 			 G_TYPE_UINT, xid, /* window xid, 0 for none */
> 			 G_TYPE_UINT, timestamp, /* action timestamp, 0 for unknown */
> 			 G_TYPE_STRING, "pygtk-devel",
> 			 G_TYPE_INVALID, G_TYPE_INVALID);
> 
> This pops up a window a bit like this:
> http://packagekit.org/img/gpk-client-codecs.png where the user is asked
> to confirm the action, and then agree to any EULA or GPG signing
> questions. When the software is installed, we return TRUE, else you get
> return FALSE and a nice error code and description.

 But, IMNSHO, this is a terrible solution to the problem. Apart from
looking like an API created by a 13yr old on a sugar high, the above
makes the calling package automatically dependant on dbus ... and not
anything PackageKit related.
 Also, as the rest of this thread shows, there's no good way to pick a
good 9th (9th!) argument. None of the proposed hacks would work for:
"./configure && make && make install" ... which kind of makes the whole
point of PackageKit seem moot.

 I would normally just wait for it to be fixed, but it looks like you're
proposing the solution as basically done ... when it doesn't look to
have really started, yet.

-- 
James Antill <james at fedoraproject.org>
Fedora