Hello! Mauro and Leon offered to take over maintenance of meta-tizen and tizen-distro. Once https://review.tizen.org/gerrit/#/c/41288/ gets accepted, they'll be able to update the repos. They will also get ownership of https://review.tizen.org/gerrit/#/admin/projects/scm/bb/tizen which is the repo which contains the spec2yocto tool and its configuration.
I seem to be the last one left who (albeit only briefly, compared to the rest of the team) worked on this, so let me do a brain dump of what I know about it. But first, a word of warning to set expectations right: the current "Tizen on Yocto" based on conversion from spec to bb files has always been a prototype. The approach has known limitations (see below). It was meant to be replaced by a setup where most packages come from upstream OpenEmbedded and Tizen-specific projects get maintained in additional, hand-written.bb files, with those .bb files getting converted to .spec. Obviously we didn't get that far. As a side note, the https://github.com/01org/meta-intel-iot-security is a repo containing such hand-written recipes for several security mechanisms from Tizen. http://git.yoctoproject.org/cgit/cgit.cgi/meta-translator/ is the tool that translates .bb files into .spec. A conceptual issue of spec2yocto is that it has to work with .spec files which don't have enough information to generate recipes for cross-compilation: when cross-compiling, one needs to know whether a dependency is for the native host or for the target system. The .spec file does not say, so the tool uses heuristics which are sometimes wrong. Another issues is that .spec files rely on OBS' handling of circular dependencies (by expecting some older version of the packages to be available already), whereas bitbake builds from scratch and thus circular dependencies need to be avoided. See D-Bus + Cynara in the meta-intel-iot-security repo for an example of that (currently pending in a pull request). Because the .bb files are auto-generated, they are not particularly nice and do not follow OE best practices. But the main limitation of spec2yocto is that it only converts one particular spec build configuration (currently x86) and only one profile into .bb files. All conditional changes in .spec files get lost and need to be re-added manually. The process for fixing ,bb files via -extraconf.inc files is very fragile. In several cases, entire sections from the generated .bb file were copied and modified, which then had the effect that future updates to the generated .bb file got ignored. When I started working on it, I proposed (and later used) a slightly different process involving branches: one for unmodified generated files, one pulling from that via "git merge" with manual changes, and one main branch with one commit containing all updates (automatic and manual) squashed together - see https://lists.tizen.org/pipermail/dev/2015-January/006017.html and the https://wiki.tizen.org/wiki/Build_Tizen_with_Yocto_Project#rev_ivi_2015_02_04 snapshot that I released based on that process. The spec2yocto README.md (https://review.tizen.org/git?p=scm/bb/tizen.git;a=blob;f=README.md;h=99a2d1ee36a5fe2429ff70e45e67527001c427f8;hb=refs/heads/tizen) contains some setup instructions for refreshing from Tizen. If I remember correctly, one has to check out scm/bb/tizen in the same directory as meta-tizen, then enter the "tizen" directory and run "spec2yocto" there to update recipes in "../meta-tizen". When others took over, they tried to keep both IVI and Common in the same meta-tizen branch by copying the entire IVI recipe tree into the meta-tizen-ivi directory and starting anew for Tizen Common (at least as far as I understand it - I haven't paid that much attention to that). As a result, previous fixes like the one for "-j16" got lost. I would have done it differently: branch off IVI, change spec2yocto config to convert Tizen Common, refresh recipes, merge with manual fixes, updated main branch, and then focus on Tizen Common. It's up to you to decide how you want to continue. One more word about tizen-distro: that repo is put together using the OE combo-layer tool. The goal is to not modify anything other than the combo-layer config itself in tizen-distro and instead pull all the rest of the files from component repositories like meta-tizen and openembedded-core. I see that you started to patch files from openembedded-core in tizen-distro. This will lead to problems down the road when updates from the modified component no longer apply to your modified copy. It is better to avoid such issues by making the change in the component (if you can) or using another layer with .bbappend files or overriding .bbclass files for the fixes. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
