On Fri, Aug 28, 2009 at 04:47:53AM +0100, Gary C Martin wrote: > Hi Benjamin, > > On 28 Aug 2009, at 03:58, Benjamin M. Schwartz 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: > > What would be your recommendation? As a long time Mac user (and > developer) I was/am all for "fat packages" (universal binaries), and > we certainly don't have the ability to compile binaries on demand for > the significant portion of target sugar HW. Activity bundles are a > major plus, from where I'm standing, vs. the traditional ./configure, > make install, and dependancy requirements. > > With my activity author hat on, I've gone out of my way to avoid the > hell of binary blobs, it breaks the whole idea of providing code in > Python source for others to easily edit, modify, learn from. But I > understand (having adopted maintenance of some old projects) that this > has not always been possible for authors (though it woul would always > be my goal when writing code).
Another option is adding 0install[1](or so) to sugar e.g.: * activity bundles dont include any blobs at all * on uploading .xo to journal, sugar popups 0install regular dialog to install all needed by activity dependancies * activity author "package"(in meaning of packaging in 0install) binary dependancies for all environments/plarforms/architectures that he wants to support Purposes for 0install(or so) in comparing with native packages: * one way to install deps in all environments * non-root install [1] http://0install.net/ -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel