[Sugar-devel] jhbuild improvement?

[Bernie Innocenti]

On Fri, 2011-09-30 at 13:33 +0000, Aleksey Lim wrote:

> Actually, I don't see any principal difference between Sweets approach
> and using "sudo ./install-deps.sh". To have bulletproof Install-deps.sh,
> we either need to support only one distro (and maybe only one its
> release), or I don't see any difference in possible issues (w/ missed
> deps, wrong package names, wrong dep version, etc) that might be popped
> up while using "install-deps.sh" or sugar sweet. If something goes
> wrong, just open "install-deps.sh" or "sugar/sweets.recipe" and changes it to
> make it useful in your system. The difference is, for sweets.recipe, you
> have to change the string:
> 
>     requires = dep-1; dep-2 > 0.4
> 
> but for Install-deps.sh, you have to change the code in Install-deps.sh
> with bunch of ifs (for all supported native PMS and bunch of package
> name mappings). All these issues are covered out of usage workflow. Yes,
> there are downsides, because it is a possible breakage point. But all
> these issues (not directly related to packaged software) might be solved
> by skilled people (who support all these deps on Sweets level) or
> every user have to solve it on his own (and so for every user).

This is what the install-deps.sh looks like:

  http://git.sugarlabs.org/sugar-core/mainline/blobs/master/install-deps.sh

As you can see, it's quite low-tech: those who can't make sense of this
are probably unable to hack on the Sugar codebase either.

I opened sweets.recipe, but I couldn't immediately figure out where the
python-box2d dependency was coming from. Of course I could have spent
more time learning about zeroconf and digging into the
inter-dependencies...

Instead of investigating further, I stopped there. By that time I had
already determined that the learning curve for a new Sugar developer is
a lot steeper than it had to be.

Look, there are other veteran programmers who seem to be frustrated by
our current build system:

  http://marcopg.org/2011/09/06/building-sugar-from-git-on-f15/


> > 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.
> 
> http://wiki.sugarlabs.org/go/Platform_Team/Recipe_Specification
> The good point, it is inherited from activity.info format.

Nice documentation and nice design!

I'm just unsure what the values of requires= are supposed to be: native
packages? zeroconf packages? or sweets? Where can I find a full list of
them?


> The only multiple distro support in Sweets, is having a map between
> Sweets level dep, e.g., "base/gtk" and names of native packages in
> particular distro https://packages.sugarlabs.org/project/monitor?project=base
> ie, Sweets/0install need to decide what native packages needs to be
> used/installed instead of "base/gtk".

Super nice. I think we could make things easier to understand by
increasing the verbosity on stdout.

Something like "building base/gtk from source because $EXPLANATION".
Simply failing in case of missing dependencies would also be acceptable
(actually, it's a lot less confusing than being too clever).


> Well, there is no magic. For skilled people, there is no need in
> anything except glucose sources (no need in jhbuild or sweets). For not
> so skilled people, we either need to ask them to be skilled, or put
> some magic somewhere. In ideal situation, all deps will be in native
> packages and will be installed mostly in a sustainable way

My claim is that we're *already* living in this ideal situation: the
mayor distros already include everything we need. If someone is using an
older distro, it's much better to tell them "please upgrade" than try to
do something too clever and then fail in the middle.

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