[Dev] Tizen on Yocto status + maintenance
Mauro Carvalho Chehab
mchehab at osg.samsung.com
Sat Jun 13 13:02:47 GMT 2015
Em Fri, 12 Jun 2015 13:56:28 +0200
Patrick Ohly <patrick.ohly at intel.com> escreveu:
> 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
> 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
> 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
> 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:
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:
Could you please review and check if those are ok?
More information about the Dev