[email protected] wrote: > Hi, > > Just took a look at 1.0.99.3. 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! _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
