No subject

ask on the mailing list. It might already be on the TODO, or we might
have to slightly tweak the API to make it possible."

I this case we just have to tweak the API. And I'm here to help you with that.

> For example, get_mime_types
> and install_files are not needed by a source-based distribution as you can't
> untar a package to get it installed.

Sure, in this case you just don't handle those two methods if they
don't make sense. They are not mandatory.

> Anyway, while there are only unneeded things everything is good but I think it
> could be great to add a new backend function that could be
> backend_compile[_package]. It could be better for user because seeing
> "installing foo package" for minutes or hours can be confusing. For sure, Gentoo
> user's know they will probably be compiling stuff is probably better.
> As a first step, this function could be called if defined and maybe if some
> backends need it for source/binary packages, it could be more flexible ?

We can't do this, as you have to bear in mind the GUI has to be
backend neutral. We can't have something like this:

#if BACKEND is PORTAGE
pk_client_compile ()
#endif
pk_client_install_packages ()

But, what we can do is present meaningful information to the user when
they install, for instance:

Starting compiling phase...
Compiling hal...
Linking hal
Cleaning up hal....

You have to remember that the user just wants to add package, the fact
that it has to be installed is just an implementation detail.

So, all we really need to add is some PkStatus enums (see
lib/packagekit-glib/pk-enum.h) and maybe some PkInfo enums if you
think it's needed. I don't mind adding lots of enums if it makes
sense, and I think it makes sense in this case.

Note: When we add enums, we also have to add translations and icon
mappings in gnome-packagekit and KPackageKit tools, although leave
that to me.

I hope that helps,

Richard.