[packagekit] portage backends filters

[Zac Medico]

Mounir Lamouri wrote:
> Sorry for the top-posting but it's easier to summarize with gmail...
> 
> non-supported confimed:
> - devel
> - basename
> - supported
> 
> supported confirmed:
> - installed
> - newest
> - free: why not playing with ACCEPT_LICENSE and license groups instead
> of PROPERTIES ?

If you can create @FREE license group and ACCEPT_LICENSE="@FREE"
will give correct results, then it seems like that should work fine.

> may be supported with new PROPERTIES:
> - gui
> - application
> comment: not sure that's needed but it could be proposed and i'm not
> sure gui/application distinction is really good (most application are
> gui and all gui should be application)
> 
> need discussion/confirmation:
> - visible: after Richard comment, I think it could be abandoned and I
> don't think adding unmask in PackageKit is a good idea, it's a door
> open for a lot of issues.
> - source: Zac, you answered only on the technical side. Do you think
> there is a real need for a source filter ? I mean, not using source is
> possible but is it viable ? Do we want to disable most part of the
> packages ? I've never used binary packages so I don't know if using
> only such packages is viable.

It's probably best to leave this filter unimplemented for now, since
gentoo itself doesn't officially distribute binary packages (yet).

> - collections: Richard, why this filter has been added ? I can't get
> the real need.
> - arch: The distinction between x86 and x86-64 is made with
> ACCEPT_KEYWORDS and then, there is multilib profiles. Don't you think,
> this is already managed by pre-packagekit configuration ? (ie.
> /etc/make.conf)

Since ACCEPT_KEYWORDS is only a visibility hint, I wouldn't say that
it applies here. The fact that we have amd64 and x86 keywords can be
considered coincidental. When source is converted to binary, the
result is controlled by variables such as MULTILIB_ABIS and CHOST
that come from the profile, rather than ACCEPT_KEYWORDS.
-- 
Thanks,
Zac