[packagekit] Listing all packages

Richard Hughes hughsient at gmail.com
Thu Jan 10 15:09:04 PST 2008


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.





More information about the PackageKit mailing list