[Sugar-devel] [Systems] New ASLO Bundles on the Mirror
bernie at codewiz.org
Wed Jan 7 13:38:51 EST 2015
On 01/06/2015 08:20 PM, Sam P. wrote:
> - Binaries built for different architectures (i686, x86_64, arm...)
> Do you have an example for this? I tried physics, but it does not have
> a native part. I will try and use git-annex or a similar solution, as
> discussed on irc.
IIRC, the Physics bundle contains multiple binaries for box2D, one per
So actually we've been doing multi-arch bundles, a bit like OSX, rather
than one bundle per architecture. I'm not sure this scales well, but if
we only support 3 archs that's not a concern.
However, building multiarch bundles from source can get tricky because
they need multiple cross-toolchains and all the target libraries. I bet
the Physics' XO bundle was built manually, i.e. by taking pre-built
binaries of the box2D from different places and dropping them into the
right folder before invoking setup.py. This is far from being ideal, but
the complexity of build systems tends to explode when you want to cover
all the weird corner cases.
> - Bundles manually pinned by deployments. This is crucial for
> deployments that do their own QA and can't tolerate breakage during the
> school year. The ASLO updater never supported this very well, and thus
> many large deployments kept using the "microformat" updater along with a
> wiki page or a static html page hosted on their infrastructure.
> IMHO, deployment can easily deploy their own new ASLO copy and manually
> edit or rollback or not update the data files. It is relatively easy to
> deploy your own new ASLO frontend and updater dataset (part of
> frontend). I should probably reach out to developments doing this.
Ask Walter, he knows them all.
> Sorry for dropping so many new requirements on you, but... Replacing a
> production system is a lot harder than designing something anew :-)
> That's fine :)
_ // Bernie Innocenti
More information about the Sugar-devel