[packagekit] portage backends filters

[Mounir Lamouri]

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 ?

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.
- 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)

Thanks,
Mounir


On Wed, Jun 24, 2009 at 9:38 AM, Richard Hughes<hughsient at gmail.com> wrote:
> On Tue, Jun 23, 2009 at 10:22 PM, Mounir
> Lamouri<mounir.lamouri at gmail.com> wrote:
>> And the interesting part it's the packages I'm not really sure about:
>> - arch: according to filters doc [1], it's for multilib support (x86-64
>> using x86) but it's not managed like that in Gentoo. So we can use it to
>> "unmask" not keyworded files or use unstable packages. But as it's not
>> really done for that.
>
> If I'm sitting on a x86-64 PC, I could install dave.x64 or dave.i386.
> If the arch filter is specified, then I only get the native
> architecture packages, for example dave.x64. This means that we can
> DTRT in 99% of automatically-install cases, unless the user wants to
> install the 32bit plugin, in which case they probably know they don't
> want a native arch.
>
>> - visible: not really clear what it should be. I was thinking it could
>> be used to unmask some packages.
>
> You probably don't need this. This is designed to be used where you
> were sitting on a smartphone, and you want to only show totem and
> mplayer, and not mplayer-libs, libplparser, totem-playlists etc.
> Visible packages would be manually tagged by a repository manager.
>
>> For packagekit-list member, I'm sorry this message is pretty
>> portage-oriented. It's much more for your information and to have some
>> clarifications about some filters and have some opition. Especially Zac one.
>
> Don't apologise. Discussing the concepts of filters with a bias on
> portage probably affects conary or yum too, so really don't worry.
>
> Richard
>