[Sugar-devel] jhbuild improvement?

[Aleksey Lim]

On Thu, Sep 29, 2011 at 11:17:42PM -0400, Bernie Innocenti wrote:
> On Thu, 2011-09-29 at 23:30 +0000, Aleksey Lim wrote:
 
> > 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.

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

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

These are regular packages within Sweets, so np. The cumulative sweet
might be named, e.g., sdk/platform.

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

http://wiki.sugarlabs.org/go/Platform_Team/Recipe_Specification
The good point, it is inherited from activity.info format.

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

Well, thats a quality of particular sweets and needs specific
investigation..

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

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

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

yup, I'm creating sdk/platform

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

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 (the weakness for
install-deps.sh is a lack of IFs to cover all possible situations, the
weakness of Sweets, is a lack of support of deps that need to be pointed
to the native packages (ie the same IFs but delegated to dep
maintainers)). In other words, I don't see principal difference between
install-deps.sh and Sweets here, i.e., both ways have downsides - in the
1st case people have to be skilled to solve possible issues by changing
the install-deps.sh, in the second case not skilled people have to ping
bad dep's maintainers and skilled people can fix the issue (by skipping
the bad dep or checkout it and fix its code).

More over, install-dep.sh way is mostly included to Sweets,
i.e., to have Sweet way useful for sugar, there are:

* light patches for sugar to make local launch possible (w/o hacks in
  the system, or chroot - only sugar sources and some envars to run sugar
  just from the place were it was cloned)
* sweets.recipe in sugar sources that contains info for deps and what
  "./configure && make && make install" needs to be called)

what people need to (in ideal) is looking to the "requires" section of
sweets.recipe to install these deps (and figure out what "gtk" means in
their system) and do the same as in "make" section.

-- 
Aleksey