On Oct 21, 2011, at 4:05 PM, ext Carsten Munk wrote:
> 2011/10/21 Lauri T. Aarnio <[email protected]>:
>>
>> That is in fact what we did for an experimental SB2-based SDK for Harmattan.
>> There are even two perls, the ARM version and the x86 version (both are
>> known as /usr/bin/perl.) They don't have to have similar configurations; the
>> x86 side contains only selected tools and doesn't have to be updated so
>> often.
>
> Okay, so, let me elaborate - what I meant was - imagine this situation:
>
> 1) Source package build-depends on, random example, perl-SSLeay, which
> is a perl extension that's built with native code
> 2) We have SB2 doing mapping to a x86 perl and has selected
> tools/extensions compiled for x86 too which doesn't include
> perl-SSLeay
That is where your assumptions go wrong.
It isn't done like that. Or should't be, x86 perl must not used for running
scripts from target packages - either from the source package or from target's
binary packages. It simply isn't safe, and there are packages where it fails.
Badly.
Note that I'm now describing the correct way of doing it (SB2 can in fact be
used to do just about anything ;-), this how the "accel" and "devel" modes do
it:
SB2 uses a simple exec policy based perl selection: Target scripts are executed
with target perl, and tool perl scripts with the x86 perl. This is the only
safe way how it could be done automatically.
It means that your example source package will only need to get the target
version on perl-SSLeay, and it will be executed with target perl in qemu. Note
that we can't know if the script is also going to load an extension which was
just compiled...
On the other hand, if your set of tools includes perl scripts (like the various
dpkg-* utilities for debian), those will be executed with the x86 perl.
(if you want to know how it is done internally; the implementation decides what
#!/usr/bin/perl means based on where the script is located on the real FS)
> I feel there's unforseen consequences if we don't keep sources and
> versions in sync on both X86 and ARM side, just try to remember how
> much of a mess SB1 devkits turned out to be in non-upgradability and
> being out of sync with what actually existed :) - and potential
> differences in how a native machine would build a package vs how a
> cross compiled one would be.
Don't try to refer to SB1 devkits in this context. SB1 and SB2 are different
things, not sharing code, nor too many practices.
There is a lot of things that can be - and have been - solved with SB2's rules,
but are difficult (if not impossible) with chroot.
> I'm aware this approach with maintaining a tools distribution that
> doesn't have to be updated so often probably works in a
> most-developers-inside-one-company and strict requirements/dependency
> checking but this was a problem that people in community hit quite a
> lot when building software for Maemo as an example.
SB1's devkits were a maintenance nightmare. Forget the devkits.
SB2's tools collection is based on two ideas
1) the contents must be built from the same sources as what goes to the target
FS
2) it doesn't have to be updated so often, because it doesn't contain as much
stuff as what goes to the target side. And updating it could be automated.
The big question is that what should go to the tools collection (what can be
put there, what can't). Some tools are easy to handle, some require more work
(like perl & python). But this is not something that would create an endless
maintenance loop.
> That said - if you keep the source packages in sync (as OBS can do)
> and map a x86 version instead of ARM version of each
> interpreted-language-extension through SB2 mapping, it might work.
>
> I'd like to see a SB2 approach to OBS building of RPMs - it might have
> some benefits (such as non-root local builds) and perhaps can do it
> faster. Would be good to get statistics on the table for what speed
> benefit it has :). If you'd like to start with that, you can try to
> package up sb2 for RPM, and hack the 'build' package to be running SB2
> instead of rpmbuild. You can do this on local builds too.
I have been prototyping just that... it isn't integrated to OBS yet, but
rpmbuilding with SB2 is possible. And easy.
> But a definite no to a tools distribution that we map to that's not
> updated so often. It's a maintainability nightmare.
maybe distribution is a wrong word, configuration might be a better one.
As soon as you stop thinking about the SB1 devkits, you might notice that it
isn't a nightmare :-)
> Packages that are
> being built should be built using tools that are from the OS they're
> being built for or we're in for a world of hurt.
Fully agree. 100%.
Lauri
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
