[packagekit] Listing all packages

[Richard Hughes]

On Thu, 2008-01-10 at 11:03 +0000, Thomas Wood wrote:
> On Wed, 2008-01-09 at 19:13 +0000, Richard Hughes wrote:
> > On Wed, 2008-01-09 at 17:43 +0000, Thomas Wood wrote:
> > > There doesn't appear to be a way for a PackageKit client to request a
> > > list of all the available, or all installed packages, from PackageKit.
> > > 
> > > Is this intentional, or should the functionality be available through
> > > the search functions?
> > 
> > Well, no! What do you need the package list for? The SearchX functions
> > shouldn't search for strings less that two chars, and some backends
> > limit the results to the first 100. If you need this functionality I
> > think a new function might be sane, without a search term but with
> > filter functionality.
> 
> So I've just been discussing how this requirement came about, and how it
> may or not be solved.
> 
> Firstly, our front end will mostly consist of lists of packages, split
> into logical groups. However, the current PackageKit groups enum does
> not quite cover the sort of separation our front end requires.

Do you have a list of your groups? I don't mind adding in group types
where it  makes sense as I think this is what you should be doing.

> Secondly, our front end only wants to display a small subsection of the
> entire repository. This can be thought of as "end user applications",
> which may or may not be GUI. However, in all likely hood most of them
> will be GUI applications, but the method to determine them will be
> specific to our distribution as there are no standardised section names
> in Ipkg.

Gotcha. How do you decide what is to be displayed and not?

> The second problem is quite easily fixed by defining the "gui" filter at
> compile time. However, I am not sure whether it is acceptable to add
> configure flags for individual back ends. This could easily be done with
> a small patch instead.

No need, we just need to create another filter enum, something like:

* application and ~application (or)
* custom and ~custom (or)
* special and ~special

Adding enumerated types is cheap - and makes sure that we don't start
overloading other types and breaking the logical design.

Richard.