Hello!
It was already mentioned here that there is work on a conversion tool
from BitBake meta data as used by Yocto (.bb files, called recipes
there) to .spec files. Let me summarize where we are with that.
The tool itself will be a provided as a new Yocto layer and may also be
of use elsewhere. At the moment we are waiting for approval to publish
it. For Tizen, the meta-tizen layer will have a custom class for
activating the conversion in a build config. The output are .src.rpm
files containing source and .spec files.
I started applying the conversion to recipes identified in the "Tizen on
Yocto" spreadsheet [1] as suitable for copying from Yocto, then I
imported them into a home project in OBS derived from Tizen:Common [2].
Whenever possible, I fixed or enhanced the converter instead of doing
Tizen-specific post-processing of the generated .spec file. So far, that
has not been necessary at all (although the tool would allow it).
However, the converter needs some additional information:
* a definition of the groups that Tizen uses for packages; this is
currently set in one file, but could also be done by individual
maintainers
* a definition which packages require ldconfig calls during
(de)installation; Yocto determines that automatically as part of
building binaries, so the information is not in the .bb files
that serve as input of the converter
* renaming rules for some packages that are named differently in
Yocto than in Tizen (for example, sqlite3 vs just sqlite); this
could be avoided if we switched Tizen over to the names used by
Yocto
There are some differences that I don't consider relevant but are worth
pointing out because others might disagree:
* Yocto has default patterns for which files go into which binary
package. In .spec, exact lists must be provided. To avoid the
need to maintain these file lists by hand on top of the less
specific patterns in Yocto, I wrote a file list generator tool
which replicates the Yocto logic at the end of the rpm install
phase. I personally prefer the less cumbersome Yocto approach,
but it has the downside that changes in the compilation might
lead to more or less files getting packaged than in the past,
without triggering an error during compile time. If a maintainer
prefers to maintain exact file lists, he or she can do that by
disabling the file list generator in a recipe.
* Trying to use Tizen's %find_lang macro [3] turned out to be more
trouble than it was worth, so the Yocto -locale packaging is
used instead.
* A side effect of the automatic approach is that each .spec file
defines the full set of -dev and -locale packages. rpmbuild then
always creates them, even if it turns out at compile time that
they have no content. It would be possible to disable those
empty packages on a per-recipe basis.
At the moment I am converting 160 recipes. 94 compile successfully. Only
12 required Tizen-specific tweaks via .bbappend files (for example,
splitting out libraries or adding the /bin/sh symlink to bash). 43 fail
to compile. 16 have missing dependencies. 7 compile, but had to be
disabled because the resulting binaries are not compatible with Tizen
and break further builds (wrong version of shared libraries, coreutils
depends on update-alternatives).
The biggest gaps in the converter are:
* mapping of .bb PACKAGECONFIG to bconds checking and building the
packages in OBS with different build configs
* support arch specific changes; only 14 recipes have that and
some more of the differences probably can be avoided, but not
all. For example, speex has arch specific configure options.
Next steps besides that:
* actually use the new .rpms and/or compare them against current
ones to detect regressions
* analyze more of the build failures and dependency issues
[1]
https://docs.google.com/spreadsheet/ccc?key=0AiN0rVNGA72PdDhDNjVyeThvX2dkMkFUSEhvNWZKR2c&usp=drive_web#gid=0
[2] https://build.tizen.org/project/show?project=home%3Apohly%3Acore
[3]
https://wiki.tizen.org/wiki/Packaging/Guidelines#Why_do_we_need_to_use_.25find_lang.3F
--
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
[email protected]
https://lists.tizen.org/listinfo/dev
