[packagekit] Multiple entries to WhatProvides and SearchFile

[Richard Hughes]

Whilst converting gnome-packagekit, I'm trying to push back features
into glib2 (and the daemon) that make logical sense, rather than
duplicate the functionality in every GUI client. One example is the
font installer code.

This needs to do WhatProvides on a string array, rather than a single
string. It makes the GUI client much more complicated as it has to
send off multiple requests, and wait for them all the come back with
results. In this case if a single request doesn't match it's not
classed as failure, but the remaining results are returned. The GUI
client then has to filter duplicate package_ids.

For 0.5.x I propose allowing WhatProvides and the Search* methods to
be sent multiple&requests&joined&up&with&ampersands, which the
backends can split and return results for. For 0.6.x I propose making
the WhatProvides and Search* methods take string array rather than a
string, which allows basic ORing of data (which breaks API, but makes
the API less magic). This would allow us to do
SearchGroup(["games-gui","games-text") in one method without having to
do two searches, and then remove the duplicates manually (and breaking
the filters in some cases, e.g. newest). This would then match the
Resolve semantics, where you can do Resolve(["DeviceKit","devicekit"])
and get the correct package_id for debian and fedora.

The only need to do seporate requests would be if the application
needs to check that all provides exist, or if the client needs to know
what request matches what package. Both of these seem much less likely
than the "give me anything that matches" use case.

99% of the actual real world users for SearchName, WhatProvides etc.
only ever use one parameter as the search term at a time, and so not
converting a backend for the next release wouldn't actually break
anything, but would prevent us from using the feature in the future.

Comments welcome. Please don't change backends yet until we've reached
a consensus. Thanks.

Richard.