[packagekit] Listing all packages

[Thomas Wood]

On Thu, 2008-01-10 at 19:06 +0000, Richard Hughes wrote:
> 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.

I don't think the final list of groups is finalised yet, but the current
list should give you an idea of the sort of categories that are
required:

* All Packages
* Recent Package
* Development
* Documentation
* eBooks
* Flashcards
* Games
* Maps
* Sources

This isn't confirmed yet, but you can see it is quite removed from the
current groups enum.

> 
> > 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?

Basically any package in pre-defined certain section of the repository.
This section is specific to the distribution (and not specific to Ipkg).

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

I guess custom or special would do, but we still have the problem that
the criteria of the category is specific to the distribution, not to
Ipkg.

Regards,

Thomas


-- 
OpenedHand Ltd.

Unit R Homesdale Business Center / 216-218 Homesdale Road /
Bromley / BR1 2QZ / UK             Tel: +44 (0)20 8819 6559

Expert Open Source For Consumer Devices - http://o-hand.com/
------------------------------------------------------------