[MeeGo-dev] Compliance spec updated 126.96.36.199
Wichmann, Mats D
mats.d.wichmann at intel.com
Wed Nov 3 07:52:41 PDT 2010
Jari.Palojarvi at nokia.com wrote:
> Just took a look at 188.8.131.52. I'd like to point out one
> potential issue related to System Implementation / Platform
> Compliance and the MeeGo Core Packages list.
> If all compliant platforms must include the binary packages
> listed in the MeeGo Core Packages list, I suppose that all SW
> components in those packages are also expected to be present
> and work in all compliant platforms (%files in spec files not
> allowed to be changed)? However, as we all know, compliant
> platforms can differ from each other when it comes to
> device/HW adaptation. Device/HW adaptation typically consists
> of plugins to some user space frameworks (GStreamer,
> PulseAudio, Resource Policy, Sensor Framework, oFono, X, Qt
> Mobility APIs etc.) and device drivers ("plugins" to Linux
> kernel). And different platforms can have a different set of
> HW adaptation related plugins.
> Do the packages now listed in MeeGo Core Packages include
> device/HW adaptation related SW components that are specific
> to some HW environment? E.g. do the oFono, Sensor Framework
> and PulseAudio packages contain SW components that are not
> applicable/sensible in all environments? If they do, isn't
> that a bit problematic (components required to be present but
> not used/functional)? Or have I misunderstood something?
I don't think there's adaptation stuff in there - but I haven't
worked on the package list, just been handed it, so we'll need
to wait for others to comment.
> How should we handle/mention this aspect in the compliance specification?
There's two parts to it:
(1) bits which are unique to a whole platform family should be
in the profile
(2) bits which aren't even that common, such as down to a specific
device, need to be "fuzzed" in a way that make it clear it's a
behavior and not a specific package that is required. An example
of this style (the only case at the moment) is saying GLES is
needed but not mandating that it come from Mesa.
This kind of stuff needs to be called out to avoid the issues
you mention (e.g., requiring non-functional or not-needed bits),
and to do that, someone has to identify those piece so they
can be covered - I don't have any of that information!
More information about the MeeGo-dev