[packagekit] portage backends filters
mounir.lamouri at gmail.com
Wed Jun 24 14:04:50 PDT 2009
So, finally, will be supported asap:
May be supported if Gentoo add a PROPERTIES entry:
Can be supported but need to much work / it's too unstable to do it in
a near future:
Others will probably never be supported.
But, Richard, can I insist with collections ?
I understand it's to filter collections when searching for something
but why filtering collections ? I understand why someone want to get
only free packages or only packages with or without a gui but why
By the way, I think about supporting categories but I was not able to
test it on fedora. I must try again.
On Wed, Jun 24, 2009 at 10:28 PM, Zac Medico<zmedico at gentoo.org> wrote:
> 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.
> 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.
More information about the PackageKit