On Fri, Oct 21, 2011 at 3:05 PM, Carsten Munk <[email protected]> wrote: > 2011/10/21 Lauri T. Aarnio <[email protected]>: >> >> On Oct 19, 2011, at 2:44 PM, ext Carsten Munk wrote: >> >> 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
That is really a corner case. Most perl modules don't use XS (what you refer to as "native code") and the perl-SSLeay module has been a particular problem over the years because it has some pretty gnarly dependencies. You won't see this problem with most of the perl modules in MeeGo for example. What package as a build time dependency on perl-SSLeay? And is that a good idea? Why is a module designed to do SSL communication a build dependency? > 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 Again, this is only for perl modules that use XS. > 3) For this compile to be successful with an accelerated perl, this > extension would be have to be added for x86 too and otherwise cause a > fail in compilation due to missing extension > > 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. Seems like a pretty reasonable argument. > 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. > > 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. > > But a definite no to a tools distribution that we map to that's not > updated so often. It's a maintainability 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. But you have to recognize that people are not going to just use your packages, they're going to rebuild them. If they're not rebuilding your packages, then your particular software or image is not interesting for their particular problem. A reliance on a overly-complicated toolchain that makes the current process hard to reproduce and packages hard to rebuild on a new target or in a different build system. Everyone says "use our tool!" but in fact in open source you will find there are lots of tools, some of them as good as yours. Regards, Jeremiah -- ============================================= Jeremiah C. Foster Open Source Technologist Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)730 93 0506 E-Mail: [email protected] ============================================= === NOTE === The information contained in this E-mail message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. ============= _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
