[Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo

[Bernie Innocenti]

On Fri, 2010-03-05 at 01:10 -0500, Benjamin M. Schwartz wrote:
> 0install is just a specification and some tools.  It's not even a distro.
>  Of course there's no central build cluster.  If we want to target many
> different distributions, then we will have to provide our own build
> machines... many of them (possibly VMs).

Could just piggy back on the existing build systems provided by each
distribution.

Maybe we could give a try at the openSUSE Build Service, which claims to
build packages for all distros:

 http://en.opensuse.org/Build_Service#Features

I never used it myself, but if just half of the things they say were
true, it would be fantastic. It supports any target we would ever care
for, even some arm targets:

 http://en.opensuse.org/Build_Service/supported_build_targets


> No distro packager in his right mind would offer packages for 90% of the
> activities on ASLO.  They're crap.  This is as it should be.

Well, is this a disadvantage? I'd call this natural selection :-)


> If Sugar is working as intended, 99% of Activities will be crap.  This is
> because the purpose of Sugar is to invite novices to engage actively in
> software development.  Novices make bad stuff, and we want to install and
> run that stuff.  This means we can't rely on any transmission medium that
> requires human approval.

There are two ways to support all the crap:

(1) retain support for xo bundles support in parallel with native
packages; or

(2) add support for creating native packages in the few authoring
applications we have: pippy, etoys, scratch, turtle art. Did I missing
one?


> James Simmons has written a book about how to write Sugar Activities.  I
> want novices to read his book and make new, bad Activities.  I want to
> install those Activities as soon as they're written... may even before
> they're totally written.  This is the nature of open collaborative
> development: you run other people's pre-alpha software.  I also want
> novice developers to be able to install each other's bad activities
> without having to learn how to produce distro bundles and then shove them
> into their system package manager.

I 100% agree with you.


> I don't want the developers to have to learn three different bundle
> formats, and then build six different bundles for different versions of
> different distributions.  I definitely don't want to make them submit
> their software to five different distro bureaucracies, and then fight
> through QA five times.  I don't want to wait six months before I can try
> their Activities.

I'm sure there are viable ways around this problem:

(1) use the afore-mentioned openSUSE build service;

(2) use a conversion tool such as alien;

(3) standardize on just one package format (deb or rpm) and use a local
package db in the user's home directory (then find a way to teach it
about all the dependencies already present in the system)


> Native package systems are highly tuned for their purpose, not for ours.
> It's not even really the formats that are the problem.  It's the software
> that processes them, and the bureaucracies that control the repositories.

One doesn't have to become Debian maintainers to build .deb packages, or
a Fedora contributor to build rpms.

Today, anyone can obtain access to the centralized build clusters both
in Fedora and in Ubuntu. Dunno about Debian, but I would expect the same
level of openness. Moreover, personal repositories can be hosted
anywhere.

Native package formats are somewhat easier to deal with than our custom
format, thanks to the maturity of their tools and documentation.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/