Hello all I received a question about whether GENIVI components are integrated in Tizen IVI and if they are built using meta-tizen. This triggered me to post a response with comments to the mailing lists:
For yocto/oe based builds, the recipes for newly developed software from GENIVI plus the baseline image definitions are in the layer named "meta-ivi" at the yocto project, and I suppose they will stay there for a while at least. 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 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? 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). 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. 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. Refactoring IVI related projects to create a shared layer for shared components is something we really should consider further in the future, but I think that comes once we have reached some threshold of shared IVI-specific components (that are not already in another shared layer). We can hold off on that for a little while, but I would say I'm a little concerned that the effort to do such refactoring is growing in Tizen if you continue on the path of forking build details into your own layer. 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?) GENIVI has for a long time also discussed providing at least a development environment based on some standard distro, (think GENIVI-software in Debian packaging as an example), and there are signs of target platforms/distros created using those principles too. This was mostly to share a long answer to a simple question. If you want to, please share your thoughts and comments. Best Regards - Gunnar -- Gunnar Andersson Lead Architect, GENIVI Alliance Infotainment, Volvo Car Corporation _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
