rnorwood at redhat.com
Mon Mar 17 11:40:20 PDT 2008
On Mon, 17 Mar 2008 18:03:47 +0000
Richard Hughes <hughsient at gmail.com> wrote:
> On Mon, 2008-03-17 at 18:52 +0100, Klaus Kaempf wrote:
> > Whats the purpose of having an enum if its semantics could be
> > encoded in 'data' ?
> Valid point, but I felt it was better to split out the type in a
> separate data flag to avoid parsing in the daemon. Plus it makes
> filtering easier, but I don't think that would be a common case.
> Ohh, and we probably need a filter parameter to WhatProvides too, as
> we really don't want to filter this on the frontend.
Is there any way that these codec-based "Provides" are different
from regular provides, aside from the fact that you're targeting the
codec and module problems now? All we're really saying is 'what
packages resolve this dependency?' I don't think any of the backends
care what 'type' of dep it is. Yum at least will treat them all the
same, unless I'm missing something. I think we'll just end up with a
bunch of duplicate code in the various backends that do the same string
matching each time.
Unless the actual string really will be different for different
backends. In that case it does make sense to do some magic in the
backends, but it's going to be a lot harder to maintain.
> > > I guess we could standardize the format for MODALIAS and CODEC
> > > although i don't think that's particularly important as we don't
> > > enforce the names of packages either.
> > Correct. Leave this standardization to the package maintainers.
> > PackageKit would push this by requiring 'standardized' capabilities
> > like e.g. 'modalias(...)' through the WhatProvides API.
> What about using the pre-defined types (e.g. MODALIAS) where we
> define a common specification, and just use GENERAL when we pass free
> text to the backends?
Hrm. Again, if the actual strings for deps are going to be different
between backends, then we might need this. Otherwise, the yum backend
at least won't care, as far as I know.
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
More information about the PackageKit