[packagekit] Supporting plugins search and installation

Naba Kumar naba.kumar at gmail.com
Mon Feb 8 10:06:08 PST 2010

Hi Duncan,

On Mon, Feb 8, 2010 at 4:21 PM, Duncan Mac-Vicar Prett
<dmacvicar at suse.de> wrote:
> On Sunday 07 February 2010 16:38:01 Naba kumar wrote:
>> Hi,
>> In Anjuta, we are hoping to make things easy for users to find and install
>>  plugins, something akin to how firefox addons are managed. Clearly, it's
>>  best to be done with packagekit. This is something many other applications
>>  with plugin/extensions support will benefit without reinventing wheels.
> I don't think the goal of PackageKit is to bring users to the problem of
> plugin management. Distros are supposed to set backend at compile time and it
> should be completely transparent to the user.
>From Richard's talk in Fosdem, I got the impression that packagekit is
equally suited for applications to abstract away distro specific
package management as much as it is meant for users to abstract away
their system installation management.

The user's package management is something that packagekit has fairly
well done, but we are trying to do the same from application point of
view. We need the abstraction to manage our things like:

a) Installing missing programs needed for certains plugins to work
which are not build deps (so that clueless users don't get amused by
getting error because package deps doesn't specify it).

b) Installing missing development packages needed for new projects.
Clearly, we want the users to be as smooth as possible when he creates
his first gtk/gnome project (which will require bunch of dev packages
that don't come with anjuta dep).

c) Allow finding and installing packages related to Anjuta, such as
plugins, templates etc. you can think of the same as additional
"Cliparts" in open office. These thing don't come with standard
installation, but something user is required to install separated to
extend functions. But I don't really want to go about re-inventing
package management in Anjuta for this, especially in distro
independent approach. And the closest support we can get is from

Right now. (a) and (b) are possible. Currently in anjuta (master) we
use absolute paths to find /usr/bin/program or
/usr/lib/pkgconfig/library.pc files. It seems to work. I learned that
it's possible to use relative paths to fine the 'provides' packages
also, which is great and takes away our assumption of absolute paths.

(c) is actually just the same case as (a) and (b) (that is finding
packages from their contents), but done in more flexible way with
wildcard rather and exact match. I think this is indeed within the
scrope of packagekit's purpose. If not, please still consider it
taking in, at least to avoid reinventing packagekit in anjuta :).



More information about the PackageKit mailing list