[Sugar-devel] jhbuild improvement?

[Aleksey Lim]

On Fri, Sep 30, 2011 at 06:04:29PM -0400, Bernie Innocenti wrote:
> 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

So, it is only for lucid, what about other debian/ubuntu. There are a
chance that the same software might have different package names.
Also, what about other distros. And, e.g., if there is a wrong package
name for not well used Mandriva, you need to change this mapping bug
in all projects that use this wrong names. The same for new distro
releases. There is also dependency restrictions, eg, recent sugar might
require recent TP but recent ubuntu LTS might don't have them (and
"upgrade your distro", is not pretty fair).

> 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...

that should be unpredictable if particular package will contain full deps
tree. for the deps tree, there is a status command:

    sweets status sdk/sugar -d

> 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.

I heard the same from people (especially from people who are used
to other VCS) when they tried git at first (though, for me Sweets is
simpler), i.e., lack of knowledge of basic things for tools they are
using :).

> 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/

And, generally, it is exactly the content of sugar* recipes.
The whole reason of Sweets (as a pms), it is to replace bunch of
wiki/how-to/INSTALL by having specs and a decent pms.

> > > 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?

http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Interfaces
wiki.sugarlabs.org/go/Platform_Team/Sweets/Glossary

> > 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).

Sure, it would be helpful. The question only is "How to do".
For now there is:

    sweets status sdk/sugar -ddv

> > 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.

Well, the other my reason for using Sweets for coding glucose, is that
it is useless to separate glucose and activities (for me it is too
"anti-sugar"), i.e., having different tools/methods for coding glucose
and another one for coding activities. I mean low level stuff like handling
deps and binaries.

If sugar can be launched just by typing "./sugar" from sources
directory, well it is fine. But it is not, there is not trivial stuff
like gconf, gtk theming, dbus service etc. And finally, I don't see
reasons to have special tool to server only glucose for that, instead of
using sugar pms.

-- 
Aleksey