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?
>> 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.
Like?
It looks like there is nothing a proper recipe can't do that MIC can.
> 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.
Do you mean, _class-native and _class-target thingies? Indeed, RPM lacks
this. No actually it does not and it's not a problem with RPM but rather
with dependency solvers. RPM can put any string into *Requires. Then
it's resolver's job to find proper rpm.
--8<---------------cut here---------------start------------->8---
$ grep Requires packaging/alsa-utils.spec
Requires: native(perl)
$ rpm -qp --requires
~/GBS-ROOT/local/repos/tizen_common_snap/x86_64/RPMS/alsa-utils-1.0.26-1.x86_64.rpm
| grep perl
native(perl)
--8<---------------cut here---------------end--------------->8---
As I am thinking about this it wouldn't even require changes to
resolvers. Some clever changes in programmes creating rpository metadata
(createrepo(8)) to add appropriate "provides". The resolvers will match
those like they match pkconfig(foo) today.
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.
> 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?
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.
>> 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.
Technically you are probably right (I know too little about .bb files to
be 100% sure). There is however "human factor". I remember the very
beginning of Tizen when it switched from .deb to .rpm packages. It was
quite easy for me because I knew spec files better than all the
sophisticated stuff in debian/ directories for others, however, I was
quite a challenge to switch.
>> 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. What Yocto has got to offer here?
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
pgp3xllCUCZCV.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
