Thanks Daniel for the writeup.

On 05/06/2013 12:35 PM, Daniel Narvaez wrote:
On 6 May 2013 11:47, Simon Schampijer <si...@schampijer.de> wrote:

"Yes sugar-runner should just work in fedora as a replacement of
sugar-emulator. It only needs to be packaged."

Why isn't it included in the sugar package, what is the advantages of
it and why the hell isn't it being discussed on the devel@ list?


(Adding sugar-devel to cc)

It has been discussed on the list before.  [1]

[PATCH sugar] Drop sugar-emulator

In short the advantages are that it's more solid, better maintained and
tested (people are actually using it for development) and it works also
from a text console, without another X11 instance running.

It's split to a separate module because

1 Historic reason. It has been developed in sugar-build, in parallel with
sugar-emulator which was at the time used by sugar-jhbuild.
2 I think it just makes a lot of sense code modularization wise. It's
something built on the top of the normal sugar scripts and the two should
not be mixed (as we have been unfortunately doing with sugar-emulator). The
separate module makes the line harder to cross.

For what it's worth I'm not completely opposed about folding sugar-runner
back into sugar  (I suppose it would make packager lives a bit easier). But
I'm not going to do that work.

The reasoning for that change are all ok.

I am wondering the following: who is using 'sugar-emulator' at the moment on Fedora (or possibly other distributions)?

I think a developer can use 'sugar-build' fine those days for his needs. It is well supported and solid, and the dependencies you need to install are the same, just that the sugar repos are built on the machine. For a developer this setup makes sense imho.

The other use case is someone who wants to try out Sugar under GNOME. For him having to install the sugar packages including the emulator and then having a nice icon to start it from is a great thing to have. He does not have to log into Sugar from his session manager.

If we think the latter is a use case we want to support, we should package sugar-runner. I would do it in a separate package for the reasoning Daniel described in his initial mail [1]: "A separate module make sense here because most users will never run this code. It's largely a collection of hacks which are not necessary when running as a normal desktop environment."

Regards,
   Simon

[1] http://lists.sugarlabs.org/archive/sugar-devel/2013-January/041398.html

_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to