[packagekit] Unsupported package groups/filters

[Richard Hughes]

On 09/09/07, Andreas <tradiaz at yahoo.de> wrote:
>
> On Sun, 2007-09-09 at 11:11 +0100, Richard Hughes wrote:
>
> > Quality.If you send me your preferred username I'll give you commit
> > access to the development server.
> That's cool. Just wait till I'm done implementing the most important
> features, I'll contact you as soon as I have searching, installing and
> removing ready.

It's probably best you get your code into git, even if incomplete. It
then allows me to change stuff like enum types on all backends without
out of tree stuff bitrotting.

> > What sort of groups does it have for example? Is it a subset of the
> > group enums or whole new set? Could you list what groups enums would
> > be good for you?
> The packages groups are totally different in Arch. They're not really
> there to be descriptive but to enable users to install multiple
> required packages easily (e.g. pacman -S gnome installs the gnome
> desktop). I just asked the archlinux team to include such groups like
> those PackageKit uses in future package builds as it wouldn't require
> any changes to libalpm/pacman and could be done whenever the need to
> rebuild a package arises. But I don't think I'll
> be successful, and even if it'd take a year till all packages are
> modified that way.

Sure. I think it's useful to know what group something falls into,
although it's not critical.

> Actually the packages in archlinux' cvs are organized in folders
> like network/editors etc.. That's why I thought there was an appropriate
> tagging by groups. Never using the groups feature and just recently
> checking the packages for it, it turned out to be different...

Sure.

> Despite they don't fix the problem with archlinux those functions sound
> good and are worth adding if it helps other package manager like yum.
> Having a group "All" might perhaps help. On the other hand
> it breaks the design principle by not actually being a group.

We shouldn't use "all", as it doesn't allow us to add API in the
future. Just list what you can do in the backend.

Richard.