Hi,
(Lauri can hopefully correct if I got something wrong.)
On 10/21/2011 04:46 PM, ext Carsten Munk wrote:
The case was generalized, using perl as an example - compiled code
also exists in python extensions, ruby extensions, or other things
people use for building within their packages these days. Generally:
compiled code extensions for anything that ought to be accelerated by
a X86 component as a use case
You aren't supposed to go and put random crap to SB2 tools root and
hope that somehow it "just works"^{tm}.
AFAIK this is how you accelerate something like Perl in SB2:
* You check which packages' scripts are safe to run with x86 version
of the interpreter (they that don't load random modules etc).
* You add those packages to the tools root.
* You use SB2 mode which states that when script is present in tools
root, it's run using tools root interpreter.
* If you want to accelerate something extra, you create your own
mapping rules.
When you replace a script package in tools root, to a newer package
in your distro, you may want to re-check that its scripts are still
safe to use.
It's a bit more work, but tools packages shouldn't be added
or updated that often, so that "time saved in compilation" > "time
spent in checking which packages can be safely used for acceleration".
With regards to 'hard to reproduce', two sides/things we've learnt from history:
1) Packages must not rely on being built inside a specific cross
compilation environment
This is what made Maemo packages so bloody hard to reproduce on top of
Debian/Ubuntu - they relied on things Scratchbox did. In the OBS
'cross' approach we try to be as close as possible to as how an ARM
machine would build the package.
This was partially bad packaging and partially SB1 devkit
design issue.
The tools provided by SB1 devkits were visible to packages
although they didn't list corresponding packages in dependencies,
so missing deps went though fine in integration. I.e. SB1 favored
bootstrapping support over normal build dep verification.
SB2 has separate modes for these I think.
Note: Debian itself isn't that perfect in this either. I've
found quite a lot of upstream Debian packages which are missing
dependencies to non-essential[1] packages because those packages
happen to be present[2] on all normal Debian systems, but were
missing on Maemo.
(I suspect that Debian doesn't care about being very pedantic
in this matter because fixing all packages could increase the deps
quite a bit which would then slow down dependency resolving and
might even create dependency loops.)
- Eero
[1] Essential = packages needed to install/update packages.
[2] Are base packages installed by default by Debian install
media.
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
