Em Fri, 12 Jun 2015 13:56:28 +0200 Patrick Ohly <[email protected]> escreveu:
> 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. Ok, so the idea is, for: - bitbake - openembedded-core - meta-openembedded - meta-qt5 - meta-tizen to send patches to those specific repositories, and then merge back using "scripts/combo-layer update <component>", right? I made some such patches for meta-tizen: https://review.tizen.org/gerrit/41369 https://review.tizen.org/gerrit/41370 https://review.tizen.org/gerrit/41371 https://review.tizen.org/gerrit/41372 https://review.tizen.org/gerrit/41373 Could you please review and check if those are ok? Thanks! Mauro _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
