[Sugar-devel] jhbuild improvement?

[Bernie Innocenti]

On Thu, 2011-09-29 at 23:30 +0000, Aleksey Lim wrote:

> Firstly, the difference I pointed is that a flexibility of using
> Sweets in comparing jhbuild to code sugar, i.e., jhbuild is a black
> box supported in a separate project that covers the full sugar related
> infra at once. At the same time Sweets is a PMS, and sugar/ here is a "package"
> in this pms. You clone the sugar sources (not ask jhbuild to clone sugar
> somewhere). Code it. And run it (right from the place you cloned it
> before).

This is indeed a big step in the right direction: it peels one layer of
indirection between the developer and the source code.

However, as long as the Sugar codebase is split into 5 repositories,
it's hard to do much without touching at least two of them. One often
needs to add an icon to sugar-artwork or change something in
sugar-toolkit...


> The second point, Sweets is a PMS. It is not an initiative to replace
> jbuild (but for me it is more useful than jhbuild), but rather to have
> on-top-of-distro PMS that support Sugar way for development, i.e.,
> learning via doing(coding), share results of experiments (because it is
> cirtical for learning process), etc.

I fully support your effort. Sugar badly needs robust package management
and a build system for activities. Sweets seems to provide this, in a
distro-neutral way too.


> > 1. The sweet binary was symlinked to ~/.local/bin/sweets.
> > Why not ~/bin, which would be already in the path for most distros?
> 
> ~/.local seems to be a common place for such stuff, If ~/bin is also
> being used in several distros (I don't have it in mine), then it will be
> a good candidate to replace ~/.local. I saw it only on Debian/Ubuntu.

I've been using ~/bin for so many years in Fedora that I assumed it was
part of the system, but now I realized that it comes from my own profile
script :-)


> PK is a critical component in Sweets. It is pretty simple, if Sugar
> ecosystem is not about "only-one-distro(put here your favorite)", then
> we either need to reuse existed PK or reinvent it. There is a good
> progress in pushing PK to several distros, I even have it on Gentoo,
> on recent Distros it just works.

Yes, agreed. It's a necessary evil if we are to support multiple
distros. However, it shouldn't be necessary to deal with PK just to
build Sugar from sources.

A simple shell script like the one that Michael (or Marco?) hacked
together for sugar-core should suffice. Such script could break, but it
won't fail in confusing and obscure ways like PackageKit and jhbuild
often do.

Here I'm looking at addressing only the needs of a specific workflow:
the wanna-be Sugar developer who tries to build the code for the first
time. I personally helped a good number of them and I shared their
frustration every time jhbuild breaks in a new interesting way.


> > 3. Sweets tried to build csound-python from sources even though there's
> > a distro package for it. Moreover, the build fails on x86_64 due to a
> > missing -fPIC. Installing the package manually with apt fixed the issue.
> > 
> > 4. Same thing for pybox2d, which isn't even available in Lucid :-(
> > 
> > 5. Why are things like csound and box2d specified as dependencies of the
> > sugar package? If I'm doing development on Sugar core, I don't care
> > whether TamTam and Physics work.
> 
> Thats not a fail of Sweets but a fail of particular sweet (ie package).
> And there is a reasong for that: for now, there is no GUI to run
> activities from Sweets (but on low level, it is possible), thus sugar
> sweet needs to include such deps

Couldn't we move these fructose deps into a separate recipe that isn't
needed when all you want to do is bring up the Sugar emulator?

> (the good point in comparing w/
> jhbuild, is that if you don't like it, you need to change sugar sources,
> not jhbuild's - edit sugar/sweets.recipe).

That's a lot better than tweaking jhbuild's ugly xml files, but it's
still a domain-specific language that I'd rather not have to learn.


> Deps issue was already covered in prev. paragraph. The building from
> sources, thats another not trivial issue. And Sweets is designed to
> solve it using another tool - OBS. Here you got building from sources
> for all deps because there are no binaries built exactly for you
> distro/arch, e.g., for now there are only blobs for Fedora-14 and
> Ubuntu-10.10: http://download.sugarlabs.org/sweets/sdk/csound-python/.
> These binaries were built on OBS in automatic manner - dev only uploaded
> sources to obs.sugarlabs.org.

Most (maybe all) of the deps being built from source stuff that exist
already as native distro packages!

If we support multiple distributions by dumping dozens binary
componentes in ~/.local, we'll end up recreating something like Red
Carpet or Zope. Such abominations resemble an operating system of their
own which takes a HUGE engineering effort to maintain and makes users
quite unhappy with the end result.



> I already mentioned this issue, in my env I have modified
> sugar/sweets.recipe that have all fructose deps commented out.

Ah, then I'll do the same... Wait, couldn't we make this the default for
everybody?


> The entirely idea behind Sweets is covering both use cases (and doing it
> reasonably well). If Sweets "packages", ie, sweets, are in good quality,
> the only steps not skilled people need to do to run sugar are:
> 
> * Install PackageKit
> * Install Sweets
> * Run sugar: sweets sdk/sugar

The last step is the problem: it really does a lot of complicated
things, including downloading binary packages and building things from
sources. Eventually something fails and you start spending your time
debugging sweets instead of Sugar.

Everything we need to build and run Sugar is already included in all the
major distros. In fact, the sugar packages in Fedora and Debian build
themselves reliably without the aid of sweets or jhbuild.

What sweets does *is* useful, but it's not the easiest way to setup a
development environment for Sugar.

-- 
 _ // Bernie Innocenti
 \X/  http://codewiz.org