Hello! The converter from .bb[append] files into .spec and source rpms, called meta translator, is public now: http://git.yoctoproject.org/cgit/cgit.cgi/meta-translator/
The branch that I am currently using is the "pohly" branch. These patches will get merged into master soon. I also have more changes brewing locally, so expect that code to change. The other piece of the puzzle are changes to meta-tizen: https://review.tizen.org/gerrit/#/admin/projects/scm/bb/meta-tizen,branches Currently my changes for that are in "sandbox/pohly/converter". To use the converter, check out both repos and branches, create a BitBake build config for Tizen (https://wiki.tizen.org/wiki/Tizen-distro_on_Yocto_Project), then ensure that that the conf/bblayers.conf has the meta-translator and sandbox branch of meta-tizen. At that point the build config will still build normal binary rpms, without the translation into .src.rpm. To switch on the translator, add INHERIT += "tizensrpm" to the local.conf. This affects normal building, so only use this build config for translation. This limitation may get removed in the future. To translate certain packages, use bitbake -c deploy_archives <recipe name(s)> To translate all packages required for a target, use bitbake -c srpm <target> .spec files will be under tmp*/deploy/rpm/specs and full .src.rpm under tmp*/deploy/sources. Conversion is done for the architecture and feature set defined by the build config. There are already patches (but not in the branch above) for translating PACKAGECONFIG into bcond checks. For ifarch checks there are ideas, but no code. In my experience, only a handful of packages have arch-specific .spec files. Before I submit the entire patch series for review, a few words about the approach taken: The tizensrpm.bbclass activates and configures the translation. Some utility classes contain additional code. Because I am building in OBS as a sub-project of Tizen:Common, the resulting .rpm files must completely replace (= have the same names and content) the original .rpm files. Otherwise I end up with two different .rpms, new and old, providing the same thing or rendering existing rpms unusable. To achieve same names, the translator renames packages inside the .spec file (SRPM_RENAME in tizensrpm.bbclass, done globally because it affects more than one recipe) and/or splits out files into new packages (PACKAGES_append in .bbappend files). To achieve binary compatibility, default package configs had to be tweaked (for example, enabling the use of openssl and versioned symbols in curl). The same .bbappend files adapt Yocto recipes to Tizen for translation and building. Where applicable, the changes above are made such that they affect translation *and* builds with Yocto. Otherwise, the _srpm override is used, which is only active during translation. The reasoning here is that it is better to minimize differences between Tizen built with Yocto and Tizen built with OBS. In the future, we can revert some of these changes and minimze the changes against base Yocto, but at the moment that is not an option (see OBS comment above) and IMHO not desirable. I'd rather minimize the changes caused by "Tizen on Yocto" in Tizen to ease the transition. Some .bbappend changes fix issues in upstream .bb files. Some have already been fixed in Yocto > 1.7 (the one we are using), others haven't been fixed and/or submitted. I tried to add comments regarding the status. We need to think of a proper procedure for that. Yocto marks the status of each source patch with certain tags; we could do something similar. If there is consensus on this approach, then I'll submit the patches to Gerrit for review. -- 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
