Created attachment 121797 [details] [review]
Initial patch for PackageKit integration

As an example, I have replaced the <required-program> and <required-package> tags for django.wiz and gtkmm.wiz. This is mainly useful to avoid throwing two PackageKit provided dialogs to the user for installing executables and libraries separately. Also, since the tags will contain the distribution-specific package names, we can use PackageKit to check whether they are installed or not if --enable-packagekit was used.

For the non-PackageKit case, we can merge the checks for executables (using $PATH) and libraries (using pkg-config) in the same function.

(I had to change the package names in django.wiz and gtkmm.wiz to match with my distribution's names.)

Created attachment 121887 [details] [review]
Refactored "missing package" portions into separate functions.

I have refactored the plugin-wizard code that deals with missing packages into separate functions in libanjuta/anjuta-utils.c so that others (like the Git plugin -- #558307) can benefit.

Due to my limited Subversion skills, I could not separate out the patch for
this bug from the one for #558307. However I have used separate ChangeLog
entries to describe them.

(In reply to comment #2)
> Created an attachment (id=121887) [edit]
> I have refactored the plugin-wizard code that deals with missing packages into
> separate functions in libanjuta/anjuta-utils.c so that others (like the Git
> plugin -- #558307) can benefit.

I would rather keep the require-program keyword in the project-wizard. It can still be useful if you don't have PackageKit and I think it doesn't make any harm.

Then perhaps we can still keep using pkg-config with require-package and add a new keyword for PackageKit. I don't know PackageKit while I know pkg-config and anyway it is mandatory for compiling.

Perhaps we can have the 3 possibilities. The project wizard can first propose to install all needed packages using PackageKit if available and then check that the right versions and the right programs have been installed using pkg-config and checking files.

... On the other hands, all these checks should be done by the configure script anyway so adding them in the project wizard is redundant. So using only PackageKit is perhaps the right thing to do.

Ok, so I let you decide. For me this patch is fine.

(In reply to comment #3)

> I would rather keep the require-program keyword in the project-wizard. It can
> still be useful if you don't have PackageKit and I think it doesn't make any
> harm.

After applying the patch, this is how Anjuta will be looking for
programs and libraries through the new
anjuta_util_package_is_installed function:
+ See if "foo" is in the $PATH of the user or not.
+ See if "foo" can be found by pkg-config.
+ Finally, if --enable-packagekit was used, see if "foo" is a package
provided by the distribution or not.

Therefore, to me it no longer looks necessary to use a separate
keyword like <require-program>.

Having a single merged tag makes life easier for the distributions who
will be patching the package names according to their own naming
conventions, and also not affect those who are not using PackageKit.
In any case, the previous two categories did not cover things like
Python modules.

> Perhaps we can have the 3 possibilities. The project wizard can first propose
> to install all needed packages using PackageKit if available and then check
> that the right versions and the right programs have been installed using
> pkg-config and checking files.

If a user is using PackageKit, then his distribution is expected to provide reasonably updated packages. eg., if the distribution provides Anjuta 2.26, then it is expected to have comparable versions of Gtkmm, WxWidgets, etc.. Otherwise it is really a bug against that particular distribution.
 
> ... On the other hands, all these checks should be done by the configure script
> anyway so adding them in the project wizard is redundant.

True. :-)

(In reply to comment #4)
> After applying the patch, this is how Anjuta will be looking for
> programs and libraries through the new
> anjuta_util_package_is_installed function:
> + See if "foo" is in the $PATH of the user or not.
> + See if "foo" can be found by pkg-config.
> + Finally, if --enable-packagekit was used, see if "foo" is a package
> provided by the distribution or not.
> 
I think it still makes sense to keep program check and library check separate. The reason is it is quite possible, although I couldn't pin-point an example, that foo can exist both as program and pkg-config (they are provided by different packages). Hence, the distinction is necessary for the wizard to tell which one is needed.

The 'package' in wizards do not necessarily mean distribution package, but it rather means pkg-config package, which in most cases is library, and can be provided by any distribution package.

So, from the above two, I think the most sensible thing to do is:

When looking for program:
1) Check if it is in $PATH
2) if not found, ask packagekit to find and install package providing this executable.

When looking for library (pkg-config name):
1) Check if it is found with pkg-config
2) if not found, ask packagekit to find and install package provideing this library.

We can't hardcode distribution specific package names in wizard. It just won't work across different distributions. Hence the need for 'Determine the package providing it'. I don't know how to elegantly handle it, but if packagekit provides a means, that would be superb.

Another thing is that you shouldn't disable git plugin because you didn't find it installed. git is not required runtime, hence configure should not enable/disable based on its existence. You can keep the manual enable/disable though.

(In reply to comment #5)

> We can't hardcode distribution specific package names in wizard. It just won't
> work across different distributions. Hence the need for 'Determine the package
> providing it'. I don't know how to elegantly handle it, but if packagekit
> provides a means, that would be superb.

Upstream Anjuta tarball need not contain distribution specific names, but I think downstream packagers will be patching it to use his/her distribution's names.
 
> Another thing is that you shouldn't disable git plugin because you didn't find
> it installed. git is not required runtime,

I did not understand what you meant by "git is not required runtime". The Git plugin does need a Git client, isn't it? Atleast that is what I understand from the code. eg., we have git_command_add_arg (GIT_COMMAND (self), "commit"); Or am I making a mistake?

Hi!
 
> > Another thing is that you shouldn't disable git plugin because you didn't find
> > it installed. git is not required runtime,
> 
> I did not understand what you meant by "git is not required runtime". The Git
> plugin does need a Git client, isn't it? Atleast that is what I understand from
> the code. eg., we have git_command_add_arg (GIT_COMMAND (self), "commit"); Or
> am I making a mistake?

You are talking about different things. Git is not required to start anjuta and not required to activate the plugin. It's only required for interaction with git if the git plugin is used. So, at installation/build time, there is no need to check for git. We can check once the user wants to use it.

Yes, that is what I intended to do via my latest patch. Just warn the user if he enabled the Git plugin but the client was not found initially, and use PackageKit if possible to install it later on.

Created attachment 131556 [details] [review]
New approach using InstallProvideFiles interface

As suggested by Naba on the mailing list, I have used GNOME-PackageKit's InstallProvideFiles to install missing programs and pkg-config packages. Since InstallProvideFiles expects absolute paths to the relevant binaries and *.pc files, I have prefixed the dependencies with ${exec_prefix}/bin and ${libdir}/pkgconfig accordingly.

So when a user selects a new kind of project, an attempt is made to contact GNOME-PackageKit to install any unsatisfied dependencies. If we are unable to establish contact (eg., PackageKit is missing) we resort to the earlier approach of showing a warning message.

The checks for programs and pkg-config packages are kept separate. However, they are clubbed and passed to PackageKit in one single message, because installation has some fixed overheads (eg., dependency resolution, downloading repository information) and the user experience will deteriorate if use separate messages.

What about anjuta_util_prog_is_installed()? Shouldn't it also use PackageKit?

(In reply to comment #10)
> What about anjuta_util_prog_is_installed()? Shouldn't it also use PackageKit?

If we are not using downstream distribution package names, then do we really need PackageKit anjuta_util_prog_is_installed()? After all each query to PackageKit is queued behind any ongoing operation, which can slow things a bit if the user is already updating or installing something.

Sorry, I didn't take a look at this for quite some time but I would still be interested in merging the patch. Can you update it to latest master?

Thanks!

Review of attachment 131556 [details] [review]:

Committed in master

Thanks Debrishi. I have committed your patch with following improvements:

1. Used a button labeled "Install missing packages" on the missings packages warning page, instead of directly invoking packagekit.

2. Invoke packagekit using async dbus call so that we don't worry about the time it takes to complete the operation.

3. Handle the dbus error correct and show user that either packagekit is not installed (service not available) or some dbus error occurred. The rest of packagekit errors are handled by packagekit itself.

It seems to work fine from Anjuta. But strangely my packagekit installation (which I had to install manually) didn't quite work. It couldn't find any package containing the missing files. But that's I guess packagekit issue since it can't find anything either with its own 'gpk-install-provide-file' program.