[readding sugar-devel] On Fri, Aug 28, 2009 at 12:04, Peter Robinson<pbrobin...@gmail.com> wrote: >>> Bobby Powers wrote: >>>> I think having something like: >>>> >>>> example.activity >>>> |-arch/ >>>> |-arch/x86/ >>>> |-arch/x86/bin/ >>>> |-arch/x86/lib/ >>>> |-arch/armel/ >>>> ... >>>> >>>> could work. Sugar could set an environmental variable ARCH to the >>>> relevant value, and we could have a reference activity_startup.sh >>>> which adds the correct lib path to LD_LIBRARY_PATH and launches the >>>> appropriate executable (or maybe a flag in activty.info which has >>>> sugar do this). This is still somewhat kludgy, but I'm not sure of a >>>> better way. >>> >>> Which solution we should choose is a technical discussion that deserves >>> its own thread. I'm personally not enthusiastic about the "fat packages" >>> approach, in which binaries for many architectures are included in one .xo >>> bundle, because: >>> >>> 1. It wastes space, by carrying around duplicate copies. This gets even >>> worse for >2 architectures, and even 32-bit and 64-bit x86 might need to >>> be treated as separate architectures. >>> 2. It's not future-proof. Packages that work on ARM and x86 will be >>> broken again if we try to support MIPS (like the Lemote laptops, Free and >>> perfect for Sugar), or maybe even Sparc or Power (massively SMT chips, >>> perfect for LTSP). >>> 3. It won't happen. Cross-compiling libraries is tremendously difficult, >>> so Activity developers won't do it. They'll just get it working on their >>> platform and ship it. >>> 4. It's unreliable. There is no good way to produce binaries that are >>> guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10. >>> Changes between versions can break binary compatibility. Between >>> different distros it's even worse. The Pippy activity recently >>> experienced exactly this problem due to the included Box2D binary library. >> >> I don't think we should aim for the perfect solution here, rather for >> what can work best for our restricted use cases. Otherwise we run the >> risk of not moving forward because we take a much bigger challenge we >> can actually overcome. >> >> If fat binaries are not desired, which alternatives do we have? > > There's quite a decent fedora arm secondary architecture [1] > community building up. They have a koji instance and instructions on > how to run a arm VM in qemu [2]. RPM packages can deal with arm vs > i386 vs PPC or what ever. It would be easy enough to setup various > repos and koji build instances for building native packages for each > architecture so as not to have to ship multiple binaries in each > package and then integration of PackageKit in sugar would solve the > issues of installation. I don't see why the wheel needs to be > reinvented when there's a perfectly good working solution for this > already.
One of the problems is that we want our users to write and share code without having to package it in rpm and/or submitting to koji :/ As a developer, dropping .xo support would take a lot of work from my shoulders, but I suspect our users would kill us... Regards, Tomeu > Peter > > [1] https://fedoraproject.org/wiki/Architectures/ARM > [2] https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel