[Sugar-devel] Hosting activities(and its deps) sources(and not only) tarballs

Aleksey Lim alsroot at member.fsf.org
Wed Jul 21 07:03:23 EDT 2010


On Wed, Jul 21, 2010 at 10:25:38AM +0100, pbrobinson at gmail.com wrote:
> On Tue, Jul 20, 2010 at 5:04 PM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> > Hi all,
> >
> > I'm working on Zero Sugar packaging infrastructure and wandering how to
> > solve activity tarballs/bundles/etc hoisting issue.
> 
> How does 0sugar work with multiple architectures such x86/x86_64/ARM?

At the end, 0sugar is only high level infrastructure interface to things
like:

* For distribution:
  * http://0install.net/, for decentrilized distribution of any pieace of
    sofware i.e. it is only about how to deploy some package taking into
    account its OS, architecture, dependencies.
  * PackageKit, to install dependencies from native packages
    (it is supported via 0install)
  * via sneakernet, i.e. bundling packages to .xo

* For building binaries:
  * https://build.opensuse.org/, to build binaries for bunch of rpm/deb
    based distros and arches that OBS supports
    http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets
    these binaries could be used as-is (by attaching rpm/deb repos) or
    0install
  * local build

So, the short answer, these things are designed to be architecture (and
even in case of 0install, OS) agnostic. The long answer is long... but
anyway OBS provides possibility to build binaries on several arches and
0install is designed to deploy them.

> 
> Peter
> 
> > Until now, I kept in mind only rsync access to remote directory (on
> > sunjammer by default). But I guess it is overkill to require arbitrary
> > activity developer to have ssh access to sunjammer (but it fine for
> > core/fructose developers).
> >
> > There could be, at least, several options:
> >
> > * OBS (hosted by openSUSE or SL).
> >  http://wiki.opensuse.org/openSUSE:Build_Service
> >  It is full functional packaging environment but mainly targeting to
> >  native packages. But at the end, activities could be implicitly turned
> >  (using 0sugar) to native packages just by having an analog of existed
> >  activity.info file. So, we can have one packaging/code-sharing portal
> >  for developers (in comparing with sharing portal for users - ASLO).
> >
> > * reuse ASLO.
> >  It is already used for .xo uploads, but .xo, as primary sharing
> >  model, should die at earlier or later. Activity developers will upload
> >  sources (manually or via tools like 0sugar) to ASLO via web UI or http
> >  api like OBS has (https://api.opensuse.org/apidocs/).
> >
> > Any ideas?
> >
> > --
> > Aleksey
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> 

-- 
Aleksey


More information about the Sugar-devel mailing list