Still waiting for other comments concerning whether some packages now in the MeeGo Core Packages list contain components that are not applicable in all MeeGo HW/device environments...
Anyway, I agree with point (2) below. Generally, if the compliance requirements are expressed as they now are, we need to make sure that the required packages only contain components that are sensible/needed/functional everywhere (not device/HW specific). Regards, Jari > -----Original Message----- > From: ext Wichmann, Mats D [mailto:[email protected]] > Sent: 03. marraskuuta 2010 16:53 > To: Palojarvi Jari (Nokia-MS/Tampere); [email protected] > Subject: RE: Compliance spec updated 1.0.99.2 > > [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
