On Thu, 2014-12-04 at 13:23 +0100, Łukasz Stelmach wrote: > It was <2014-12-03 śro 14:20>, when Patrick Ohly wrote: > > On Wed, 2014-12-03 at 13:34 +0100, Łukasz Stelmach wrote: > > Bitbake has an feature addressing this (shared state = sstate) which we > > will have to enable on tizen.org to get build times comparable to gbs. > > It should be possible to download dependencies if they are to be built > using the same content (source, spec, distro configuration etc.). In > Gentoo (which was an inspiration for open-embedded) it is possible to use > rebuilt binary packages together with locally compiled software.
That's exactly what the sstate is, except that it works at a different level than binary .rpm packages. > > Another feature that would be nice to have is the PR service > > (https://wiki.yoctoproject.org/wiki/PR_Service). It ensures that a > > locally built package always has a higher revision number than the > > corresponding package built by the core infrastructure. This is > > something that gbs doesn't have, which is a nuisance when > > replacing .rpms in an image (must force downgrades). > > There seem to be some hacks in GBS that give Hmmm? If GBS supports it, then I haven't seen it working myself. > > Another area that'll need work is support for editing the source code. > > In the "bitbake systemd" command above one cannot easily compile > > modified code. Markus is already working on that. > > That makes bitbake an excellent poor-man's OBS but rather poor GBS. > > I've been thinking a bit more yocto/oe/bitbake could make Tizen > development easier. > > OBS is here to stay. It is quite a good system for central building with > a good web front-end. A lot of people has learnt it, both in Intel and > in Samsung. > > GBS is acceptable as a tool to build packages locally. It uses the same > back-end as OBS which makes it less likely for a developer to need to fix > build-system dependent issues, a very important feature. "less likely" perhaps, but it's not exactly the same either. I've seen OBS build failures for compiles that worked fine in gbs. But in general you are right. > There is a gap between those: OBS is hard to set-up ad-hoc and GBS can't > rebuild large collections of interdependent packages. Bitbake/OE/Yocto > (I can't tell which of their bits exactly) can fill the gap and make > development, integration and maintenance of some base packages, which > require a large number of packages to be rebuilt with every upgrade, a > lot easier than fiddling with pre-release submits. Exactly. > MIC is a tool I like least. Partly because (which is not mic's fault) > current image configuration is spread between IMHO too many packages and > in the end one needs to extract ks files manually from an RPM. At the moment we still need MIC for full Tizen images. Yocto as it stands today can build images, but does not offer all the features that MIC has. What I have working here locally (still need to clean it up and publish) are recipes for build the Tizen qemu and a Tizen image for it which support hardware-accelerated graphics. That way one doesn't need real hardware to test the full Tizen stack. It's faster, too, because one doesn't have to copy the filesystem to the target hardware before booting. > If Yocto/OE/BitBake is capable of using RPM from repositories in OBS > (see p.1) for images, it may be used on Tizen servers as well as by > developers which will bring the same consistency GBS and OBS provide > today (p.2). It would be even cooler if it was possible to specify > one-by-one packages I would like to rebuild for an image and which to > download from a repository (e.g. tool-chains and stuff that don't go to > the image). It's not going to work quite like that. bitbake calculates hash sums of the input and output of the various stages. If the input hasn't changed, the output won't either and a cached version of it can be used, either from a previous local compile run or downloaded from tizen.org. I don't think it allows manual overrides for specific parts. > For Yocto to be really useful for Tizen (and I believe it can be) there > need to be a capable and robust spec2bb converter (I feel it is easier > to convert this way). My conclusion after having looked at converters for both directions is that bb2spec is easier. That's because .spec files lack relevant information that is needed for cross compilation. For example, when a .spec file declares a build requirement, it is not obvious whether it needs to run tools from it (in which case Yocto would need a native version for the build host) or links against files (in which case Yocto needs a version for the target). The current spec2yocto converter employees heuristics, but those have gone wrong and required manual intervention. This problem simply cannot be solved reliably. The other, more implementation related problem is parsing. The current spec2yocto converter relies on the parser to evaluate if checks and then only sees the branches which were taken. The result is a .bb file which only works in one build configuration. With Yocto, the converter has full access to all meta data and thus can replicate conditional compilation, at least for some cases (implementation still work in progress). > The amount of native bb recipes required to build > Tizen should be kept as little as possible to adhere to SPOT[1] > principle. No-one wants to maintain the same package twice. Whether that's natively in .bb or in .spec is a different question. As I explained above, doing it in .bb would be better because the bb2spec converted is more likely to do the job automatically without manual corrections. > Yocto can replace MIC, can be used instead or next to GBS but it can't > IMHO compete with OBS. Both seem to have their followers. -- 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
