No subject

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
packagekit.

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 :).

Thanks.

Regards,
-Naba