[packagekit] Listing all packages

[Thomas Wood]

On Thu, 2008-01-10 at 23:09 +0000, Richard Hughes wrote:
> On Thu, 2008-01-10 at 22:58 +0000, Thomas Wood wrote:
[...]
> > 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?

I've just received an updated list. I've put what I think is the best
match for the current group enum next to each item.


>> Communication -> ??
>> Development -> Programming
>> Games -> Games
>> GPS -> ??
>> Maps -> ??
>> Miscellaneous -> Unknown
>> Network -> Internet (?)
>> Sources -> ??


"Sources" is apparently the same thing as repositories. The repository
management is going to be done using packages because ipkg doesn't
implement any repository management functions itself, and this will be
the easiest way for users to download and "install" new repositories.


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

Sounds good, but how would the custom filter be defined? I don't want to
add vendor specific code into the backend, so the filter rule must be
passed in at configure. Or is there another way?

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