[Dev] Tizen on Yocto status + maintenance

Patrick Ohly patrick.ohly at intel.com
Fri Jun 12 11:56:28 GMT 2015


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.





More information about the Dev mailing list