It was <2014-12-08 pon 17:01>, when Patrick Ohly wrote: > 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: >>>>> 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 >> ^^^^^^^ [...] >> 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 know, and that part does not bother much.
> I think what you show here is that gbs has some overrides that prefer
> locally-built packages over remote ones. That part is working.
That's the point. It works just fine. (So why replace it?)
> 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.
--local-pkgs-path=${HOME}/GBS-ROOT/local/repos/tizen_common/armv7l/RPMS
>> 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.
So how does yocto create images without mounting files via loopback?
There are no etools like mtools to copy files to ext filesystems. I've
been grepping yocto for a while and I couldn't sport the script that
creates image files.
>>>> 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.
[...]
>> 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.
Personally I do not belive in portability of packages, neither binary
nor source. Every single distribution brings its constraints and unless
you build something as trivial as true(1) and false(1) you need to tweak
things.
>> > 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.
You mean like we would need to hack rpmbuild to get a properly parsed
spec with all the macros expanded and so forth. If it actually is that
simple to get the "state" from .bb compared to .spec (which isn't easy
to cope with outside of rpm tools, I know it) then bb2spec indeed looks
more fesible.
(That becomes boring but I will write it again)
However, the human factor (of hundreds?) of developers who put a lot of
their effort in learning how to write spec files cannot be neglected.
It's not a big deal for me, neither for some others on this list
probably, but I don't want to be that "government [that] can feed
itself".
>> 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.
The configuration (url-s, build config etc.) could be prepared with a
proper recipe, however, I admit that increased complexity may not pay
off.
OK. I can clearly see some pros of Yocto now and I am looking forward
more (a prototype that can replace GBS). There are "cons" too (not all
of them are technical), which, as of today, IMHO still outweight.
Thank you,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
pgpXfWY2yKMKY.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
