[packagekit] GetMimeTypes API addition?

[Tim Lauridsen]

Richard Hughes wrote:
> On Mon, 2008-10-06 at 07:29 +0200, Tim Lauridsen wrote:
>> but the meta-packages is the same as a collection, this is why i use
>> GetCollections.
> 
> Only for the yum backend -- this has to be an abstract interface.

I think we just limit the amount of different group types, to limit the 
potential confusion.

pk group (a group of packages, with an hardcoded groupname)
meta-package (a group of packages with an custom name)
collection (a group of packages with an custom name)
category (a branch in a tree to link collections to)

it is hard for me to see the different of a meta-package and collection
other than a meta-package is not linked to a category.
The whole meta-packages concept is easy to be confused about because
a meta-packages in some package systems is an empty package, there only 
contains dependencies, to make it easier to install stuff like gnome, 
kde etc.

subcategory is a bad replacement for collection, because it is a group 
of packages, not a category.


> What's the new group API designed to do: Return a custom nested set of
> groups. I don't think you want to link in any other logic.
> 
>>> CategoryNode(s=parent, s=id, s=icon, s=name)
>>>   
>> i dont see the need of the parent.
> 
> Well, you don't wand to encode the logic that "the left part of the id
> will be a substring of the parent -- you don't want to enforce what an
> ID looks like as you'll be using the substring in SearchGroup.
> 
> There's nothing wrong with this for instance:
> 
> S:CategoryNode("@^games", "@boardgames", "board-games", "Board Games")

> 
> So if you click on the parent, you do SearchGroup ("@^games") and if you
> click on the child you get SearchGroup ("@boardgames") -- it's up to the
> backend what input format they want to accept.
> 

I see the categories like the tree and the collections is fruit hanging 
on the tree.


The Tree:
apps
games
   action-games
   board-games
desktop
    kde
    gnome
    xfce
development
    kde
       libs

Signal:
Category(";apps",<Verbose Name>,<Verbose summary>)
Category(";games",<Verbose Name>,<Verbose summary>)
Category("games;action-games",<Verbose Name>,<Verbose summary>)
Category("games;board-games",<Verbose Name>,<Verbose summary>)
Category("desktop",<Verbose Name>,<Verbose summary>)
Category("desktop;kde",<Verbose Name>,<Verbose summary>)
Category("desktop;gnome",<Verbose Name>,<Verbose summary>)
Category("desktop;xfce",<Verbose Name>,<Verbose summary>)
Category("development",<Verbose Name>,<Verbose summary>)
Category("development;kde",<Verbose Name>,<Verbose summary>)
Category("development;kde;libs",<Verbose Name>,<Verbose summary>)

cat-id = parent;child, this way we dont send any information twice like
this one.

Category("development;kde","development;kde;libs",<Verbose 
Name>,<Verbose summary>)

i have no problems with sending parent like a separete parm., but we 
already got the needed info., so i don't see why sending it twice, buy 
us anything.

The fruits:

@quake -> games;action-games
@kde-tools -> desktop;kde
@kde-gfx-libs -> development;kde;libs

Signals:
Collection('@quake','games;action-games",<Verbose Name>,<Verbose summary>)
Collection('@kde-tools','desktop;kde",<Verbose Name>,<Verbose summary>)
Collection('@kde-gfx-libs','development;kde;libs
",<Verbose Name>,<Verbose summary>)

>>> Then you only need to send one request to the server, and you get one
>>> set of requests back, and you get an n-deep tree without hardcoding lots
>>> of policy in the API.
>>>
>>> It would be trivial to handle in python, and slightly trickier to do in
>>> C.
>>>   
>> We could limit the tree to 4 levels and always send 4 level categories
>> to make it easier to decode in C :)
> 
> No, you can't enforce such things in the API. The remit for a new group
> API is to get 100% custom group menus, and we shouldn't put such limits
> on the new API, else it's as bad and hardcoded as the old one.

No problem for me, just to make easier for the C parts.

> 
>> GetCategories() return the Categories as a 4 level tree.
>> GetCollections(catid) returns the collections in a given level in the
>> tree.
>> SearchGroup(filter,'@groupid') returns the packages in the group
>> (mandatory,default, optional and conditional)
>> InstallPackages('@groupid') install the group (only the mandatory and
>> default packages)
>>
>> in time we can replace the use of SearchGroup(filters,'collections')
>> with GetCollections("") and deprecate the 'collections' group enum.
> 
> No, I don't think this is a good idea -- there's no reason why a backend
> couldn't do something different for the collections group. For instance
> collections could be mapped to just return specific vendor groups,
> nothing to do with any distro mappings.
> 
> You have to remember that any new API can't just be added in a specific
> way just because it's done that way in yum. If for instance poldek has
> five level comps, then we shouldn't limit this in the API.
> 

fine with me.

Tim