[oe] Using bitbake in minimal chroot environment

[Frans Meulenbroeks]

2010/2/15 Koen Kooi <k.kooi at student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 15-02-10 18:19, Martin Jansa wrote:
>> On Mon, Feb 15, 2010 at 05:59:39PM +0100, Frans Meulenbroeks wrote:
>>>>> I'm just thinking about using bitbake only in minimalistic chroot.
>>
>> Already rebuilding in new chroot :).
>>
>>>>>
>>>>> What are advantages/disadvantages?
>>>>>
>>>>> How I see it:
>>>>>
>>>>> Advantages:
>>>>> 1) more secure (I started to use separate user for bitbake, when I
>>>>>    started to play with bitbake master instead release - because that
>>>>>    warning it said), but chroot is even better.
>>>>> 2) less problems when autotools pick some header or lib from buildhost
>>>>>    instead of staging
>>>>> 3) easier to check, that -native package is missing for some important
>>>>>    lib
>>>>>
>>>>> Disadvantages:
>>>>> 1) Few more MB for building environment (extra libc, gcc, binutils, git,
>>>>>    svn, sh, etc. installed in chroot
>>>
>>> If they are on the same filesystem you could use hard links and save those MBs.
>>
>> Not so big problem for me, so I used mount --bind for dirs I want to
>> share (ie /usr/portage as I'm using gentoo) and it took only about
>> 100MB.. so not a big deal
>>
>>>>> 2) More administrative to keep chroot system updated
>>>>> 3) harder to check, that autotools won't pick something from buildhost
>>>>>    in normal environment before pushing new version/recipe (ie I won't
>>>>>    have SDL libs installed in chroot, but everybody else will and maybe
>>>>>    build will fail for them after I push some recipe.
>>>>
>>>> I see this as a good thing :)
>>
>> The last point? Well it's good for me (less issues) but if I push some
>> recipe failing for 99% other builders just because they have pretty
>> standard libs on their systems, then I should be blamed for pushing
>> crappy recipe :).
>>
>>> Seems a good plan to me, please keep us posted.
>>> (actually I've been considering building in a minimalistic VM)
>>
>> Well VM would be much slower..
>
> On a recent intel/amd cpu VMs I can't measure much difference between VM
> and non-vm builds.
> My main buildmachine at work is an ubuntu 8.04LTS vm running under
> windows XP. The only major speedup I can get building in a native
> install would be using 64bit, since the VM is 32 bit, but it does expose
> both CPU cores :)
>
> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFLeZW6MkyGM64RGpERAtFOAJ9hOQA/80gWA5pzQQW9vZ34Kcmy7ACgh6vV
> zSccfttlBkf/RDcRCiYQMqg=
> =ID01
> -----END PGP SIGNATURE-----
>

Interesting results.
I had expected that ramfs would improve things. The only explanation I
have that it does not is that if you have sufficient RAM most of the
data will remain in the cache.
(although listening to the hard disk when building (dual core, 32 bit
OS, 4GB ram gives reason to suspect otherwise).

Frans.