On Fri, 2014-12-05 at 13:22 +0100, Łukasz Stelmach wrote: > It was <2014-12-05 pią 09:21>, when Patrick Ohly wrote: > > 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. > > Below I am building systemd and alsa-utils. The chroot for the latter > has systemd-devel-216-0 installed although there is > systemd-devel-216-8.2 available at download.tizen.org. > > --8<---------------cut here---------------start------------->8--- > $ cd sytemd > $ git checkout tizen.org/tizen > HEAD is now at de26b86... Add real default.target just like user has > ^^^^^^^ > $ grep Version\|Release' packaging/*.spec > Version: 216 > Release: 0%{?release_flags} > $ gbs build -A x86_64 -C > [...] > info: Done > $ cd ../alsa-utils > $ grep 'Version\|Release' packaging/*.spec > Version: 1.0.26 > Release: 1 > $ gbs build -A x86_64 -C > [...] > info: Done > $ gbs chroot ~/GBS-ROOT/local/BUILD-ROOTS/scratch.x86_64.0 > info: chroot /home/lksz/GBS-ROOT/local/BUILD-ROOTS/scratch.x86_64.0 > (tizen-build-env)@myhost /]$ rpm -qi systemd-devel > Name : systemd-devel > Version : 216 > Release : 0 <---- HERE > Architecture: x86_64 > Install Date: pią, 5 gru 2014, 10:17:54 > Group : Base/Startup > Size : 58011 > License : LGPL-2.0+ and MIT > Signature : (none) > Source RPM : systemd-216-0.src.rpm > Build Date : pią, 5 gru 2014, 10:15:36 > Build Host : AMDC1062 > Relocations : (not relocatable) > Vendor : tizen > URL : http://www.freedesktop.org/wiki/Software/systemd > VCS : external/systemd#de26b86bfcb91a3303eed38f52f32ceed8eaf08b > <--- HERE > Summary : Development headers for systemd > Description : > Development headers and auxiliary files for developing applications for > systemd. > Distribution: Tizen:Common / x86_64-wayland > $ date > pią, 5 gru 2014, 10:22:16 UTC > --8<---------------cut here---------------end--------------->8--- > > Strange, why is there "external/systemd" in VCS?
Did you perhaps clone https://review.tizen.org/gerrit/#/admin/projects/external/systemd instead of https://review.tizen.org/gerrit/#/admin/projects/platform/upstream/systemd ? external/systemd is not used anymore in Tizen 3.0. I think what you show here is that gbs has some overrides that prefer locally-built packages over remote ones. That part is working. It is more problematic to install the resulting .rpm on a real image. At least I always end up with several trial-and-error runs involving --install vs. --upgrade, with and without --replacefiles --replacepkgs. > >> 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. > > Like? Last I heard, ext4 support and installing certain kinds of boot loaders were problematic. But I haven't been involved much; Ed Bartosh can say more. > It looks like there is nothing a proper recipe can't do that MIC can. recipes intentionally don't require root privileges. That's a good thing. In a past life (MeeGo?) I had package installs running as root in a chroot mess up my bind-mounted /dev filesystem, affecting the host. Luckily that never caused permanent damage. Some things that MIC does (loop-mounting the disk image to partition and format it) require root privileges and thus cannot be done in recipes. > >> 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. > > Do you mean, _class-native and _class-target thingies? Yes. DEPENDS = "foo-native" means "I need to run a tool from foo" whereas DEPENDS = "foo" means "I need foo installed on the target filesystem during build". > Of course none of the spec files we've got today provide this > information and it needs to be put there but that is not a technical > problem with RPM whatsoever. I suppose Tizen .spec files could be extended to avoid the problem. But I am not sure whether that's desirable: it would just make Tizen packaging even more special and further reduce the opportunity to copy from others. > > 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). > > Wouldn't yocto2spec have the same problem? No, the yocto2spec translator has full access to the entire meta data the same was as BitBake has during a build run. In fact, the translator is written as a BitBake class and reuses existing code for archiving source code. > How about converting spec files to recipes on-the-fly? You treat spec > like one of source files, convert it during building with all the > variables known. That's probably feasible. But it would make using the Tizen meta data harder for Yocto-based builds, because one would have to ensure that the right OBS build config and rpm macros are available. It's also not obvious what tweaks can be done in a .bbappend file, because the base .bb file doesn't actually contain the variables that could be modified. > >> 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. > > I am not a release engineer and may not know all the details of their > work but OBS with its web frontend provides some nifty tools for them, > all the projects, requests, reviews. That's why we want to keep using OBS. > What Yocto has got to offer here? There are autobuilders. I don't know how complete their web UI is compared to OBS. Probably it's different, because it is supporting different needs. -- 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
