Dominig, > From: Dominig Ar Foll [mailto:[email protected]] > Sent: den 24 oktober 2014 04:06 > To: Andersson, Gunnar > Cc: [email protected]; [email protected]; Bourcier, Frédéric > ([email protected]) > Subject: Re: Tizen and GENIVI yocto layers, and future of IVI builds > > 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.
That's a very silly statement, Dominig. Are you nowadays trying to make cooperation difficult, or is it only by mistake? After all it's not the first instance in recent times I hear you using misleading language constructs in some apparent attempt to discredit GENIVI. Do you see the GENIVI Alliance a competitor to Tizen or something? When we have talked before I thought you understood what GENIVI actually does, so I don't understand why you would think that now? It also makes little sense, so it seems you took the chance to comment for another reason. I know you understand as well as anybody that particular implementation details should be kept independent of the general build instructions, such that generic layers are possible. If any security related details ultimately _must_ influence the original component (its source or its build recipes) then this ought to be carefully designed taking into account the upstream where the shared home is. Meta-openembedded is one of the defacto homes for shared Yocto build recipes and I see no reason why it could not continue to play a part in a secure system considering the ability to design using both .bb and .bbappends. But if you can, please provide more explanation, leaving out any childish cheapshots. At another time maybe there is time to explain what GENIVI actually does in terms of security work which is significant but I don't know if there is interest to listen. Everyone would have to stop throwing around this big word "security" however and starting saying _access control_ when we are talking about that, and use other precise terms when we are talking about other things. > 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 -- Gunnar Andersson Lead Architect, GENIVI Alliance Infotainment, Volvo Car Corporation _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
