2014-10-22 17:04 GMT+02:00 Andersson, Gunnar <[email protected]>: > Hello all > > > > OTOH meta-tizen seems a bit intrusive to me. It appears to essentially > repackage a lot of components using its own build scripts, including > the adopted GENIVI components. > > The reasons might be, (and I'm speculating here so feel free to set me > straight), that conversion from OBS to Yocto was made in a quick fashion, and > IIRC using some auto-translation.
This is correct but will not stay like that. We have selected a two steps approach, the first one by using a translator from OBS to Yocto (spec2yocto project) we have enabled the creation of a valid image in order to understand what was missing in Yocto to enable the building of an image with all the Tizen security features. This phase has allowed us to add all the required features in Yocto 1.7 which is in RC candate stage as we speak. The second phase has just started and covers two areas : - the alignement where possible (in regard of Tizen security model) of Yocto and Tizen packages version (a mail was sent in the Tizen Dev mailing list with the upgrade candidates). - alignment of the tizen-Meta layer toward a more traditional Yocto fashion. > This strategy might also make Tizen more independent which could be a risk > management strategy. But unless I'm > mistaken it is taking a step away from the layered approach that OE/Yocto > really aims for? No, that is not the case, it's just a side effect of the step approch described earlier. If combining for example meta-tizen and other layers (like > meta-ivi) wouldn't this trigger a lot of work to indicate which recipe for > each component you want bitbake to select, if they exist in multiple layers? > (I > am guessing here, haven't tried it). Yocto manages that situation quite well. But as explained before, beside of the packagres affected by the security model, full alignment is the selected working model. > > In terms of naming, the current content of meta-ivi suggests it should really > be seen as a "meta-genivi". (When GENIVI started there was no reason to > believe this wouldn't be the one and only layer for IVI extensions). But note > that -genivi in this case would mean only the new software projects that were > started in GENIVI, not the whole scope of the GENIVI specification! > Adopted components are typically built using standard layers, meta-oe, > meta-multimedia etc. As long as Genivi is happy to work without any security, that will work. As Poky has no security model, you cannot build a secured distro directly on top of Poky (Security is invasive and must be built in). > > One could propose to rename the layer to meta-genivi but in the long term as > GENIVI-initiated implementation projects become adopted, the distinction of > which project they belong to would be of less importance. I'm hoping the same > would hold true for Tizen IVI. Project-specific layers should be focused > primarily on defining distro/image content and necessary tweaks, as opposed to > build scripts for upstream components, IMHO. Maybe in such a future the > generic name (meta-ivi) will again make sense so I'm not proposing to rename > now. That is our objective, but the lack of defined Security model in Genivi does not allow to look at the consequences on such alignement yet. > > > > Just to complete the picture I want to mention that GENIVI components are also > built in non-Yocto baselines such as with Baserock, (and Tizen IVI also keeps > its > OBS/GBS based build?) So fat we support Yocto and OBS building systems. I hope that I have clarified the current situation. Regards -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
