[packagekit] Listing all packages

[Richard Hughes]

On Thu, 2008-01-10 at 22:58 +0000, Thomas Wood wrote:
> 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.

I don't really see that as a problem. I think "recent" packages is more
of a filter, not group. What do you mean by sources?

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

Sure.

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

I don't see that as a problem - we can document "special" as being
special to either the repository or the backend, i.e. vendor specific -
and it allows people shipping PackageKit the flexibility of one general
filter than can be used in cases like this.

How does that sound?

Richard.