On Thu, Sep 24, 2009 at 12:15, Peter Robinson <[email protected]> wrote: > Hi, > > Thank you Daniel for documenting all of that. I agree with your > points. There's a lot of "it would be cool if it does this" but in > most cases of deployments it just doesn't seem to be an issue. > >> 2009/9/22 Benjamin M. Schwartz <[email protected]>: >>> This is incompatible with our (or at least my) goal of allowing >>> users to throw packages around as atomic objects, without internet access >>> and without having to understand anything beyond "my friend has Sugar, so >>> it will work". It is also incompatible with allowing novices to generate >>> first-class Activities. >> >> And to throw in a contrasting view: I feel it's unrealistic and >> uninteresting for the field. (even though I would personally be >> thrilled to see this) >> >> Before I go further, I want to re-enumerate the items of discussion >> and the outstanding problems with the .xo format. >> >> >> First of all the problems with our current activity packaging: >> >> 1. Versioning system sucks, in that it's not obvious which version of >> Sugar's activity-exposed APIs each activity is compatible with and you >> can't even specify this in the metadata, and hence Sugar can't even >> reject activities that we know simply will not work on version x.y.z. >> >> 2. Because there is no user-friendly way of installing system-level >> libraries, and the bundles itself cannot specify dependencies to be >> automatically installed, and even because of a variance of system >> libraries available on different sugar distros, we end up with a >> common practice of including precompiled libraries within activities. >> This is a waste of disk space, makes bundles architecture-specific, >> sometimes even makes the bundle specific to a certain set of system >> libraries or a specific ABI even within the same architecture, and >> includes the usual disadvantages equivalent to "regular software" >> using static instead of dynamic linking (if a single bug in a >> supporting library is uncovered, multiple bits of software must be >> patched, released, distributed, built, and installed). >> >> 3. Sometimes, even though the activity does not require any extra >> libraries, an activity bundle includes native code -- for example, >> someone ports a C/GTK+ app to Sugar - this often involves the C code >> being compiled for Fedora/x86 then bundled up with a Python wrapper >> inside a .xo bundle. This has some of the same disadvantages as above >> - it becomes architecture-specific and ABI-specific. >> >> >> and, in addition to solutions to the problems described above, people want: >> >> 4. The ability to send a Sugar activity to any other Sugar user, >> regardless of Sugar version, underlying distribution and version, and >> even system architecture >> >> 5. The ability to modify activities, revert modifications, and share >> modified versions with other Sugar users. >> >> (there are other difficult/controversial things that people want too >> -- for example, a guarantee that a shared activity instance of >> ActivityX on Sugar-0.86 will continue to be compatible with the shared >> activity instance of ActivityX on Sugar-0.94, but I'll try and keep >> this discussion limited to the .xo bundle format itself) >> >> >> and features that we have already that people regard as important: >> >> 6. The ability to create a .xo bundle in a simple way from any >> platform, and ease of installation onto XO >> >> >> >> My own thoughts: >> >> 1. Versioning scheme - probably the easiest thing to discuss as it can >> be solved easily within the current format. My vote would be to adopt >> GNOME's versioning scheme of basing component and application versions >> on the version number of the platform. e.g. Write-0.88.1, >> Paint-0.86.4, etc. >> >> 2. Shipping of binary libraries within bundles - I hate this, even >> just because of the duplication. Never mind that it's become a common >> practice and is wholly incompatible with Sugar's cross-platform goals. >> I think we have 3 options available >> - switch to using distribution package systems which have already >> solved these problems. let the distributors take care of this... >> - move to a model where several .xo bundles are generated for each >> activity release (e.g. one for Fedora9/x86, one for Fedora11/x86, one >> for Fedora11/ppc, one for Ubuntu/x86, etc) >> - ban or discourage this practice, and clearly define which system >> libraries are available for activities >> >> My opinion is that distro packaging is the best option, so that >> installing the Physics activity can install a system copy of Box2D >> from distro repos at the same time. For the Sugar-side implementation, >> PackageKit would be the obvious way to go, but as a plan B it would >> even be OK (in my opinion) to individually support the common package >> managers in modular fashion. >> >> 3. Native code on the application-level only: almost exactly the same >> set of solutions as (2) and my opinion is the same. >> >> 4. Sharing of activities between hugely varying systems: The only real >> solution to this that I have seen proposed is for *all* activities to >> switch to some kind of cross-platform VM platform (e.g. Java) which >> guarantees eternal forward-compat and backwards-compat and will be >> able to run on any architecture that we might want Sugar to end up on. >> There is no other workable solution that has been discussed -- >> shipping .xo bundles with native code cannot work if we are to accept >> that Sugar runs on multiple architectures, and distro-based packaging >> is not realistically going to work on other distros, and also we >> aren't even considering the fact that the Sugar platform and the >> activity APIs are changing with every release. >> >> I feel that the one available solution is not realistic or sensible, >> and I feel this is of very little interest to deployments, who control >> and synchronize the systems (all running the same Sugar version on the >> same distro on the same architecture) and have good distribution >> mechanisms for their users. It's something we'd invest a hell of a lot >> of time into fixing, without benefit in the field. >> >> 5. Modifying activities: A noble and interesting goal but unlikely to >> happen in the field (remember, 6-12 years old users!). I'd like to see >> us move in this direction in future, but first I'd like to see us >> solidifying the platform and solving the problems/adding missing >> features which are actually of importance for deployments. >> >> 6. Ease of creation of activity packages >> Moving to distro-based packaging will not effect the difficulty of >> developing activities, since packaging is something you do after >> development, not before. >> It will affect packaging and distribution. My suggested model (as >> employed all over the open source world) is that the developers would >> release source distributions and let distributions do the packaging >> and distribution. >> Even though a Sugar system with distro-installed packages is crippled >> (activities cannot be erased or updated through any realistic means), >> we've *already* found some great packagers from Ubuntu, Debian, Fedora >> and SUSE who have been distributing activity packages. >> In many cases it will be enough just to point out to distros that >> you've developed an awesome new activity, but maybe in some cases we >> will have to lend a hand to those distributions in order to get things >> packaged up. However, there are also a huge amount of people with >> packaging expertise who are keen to help. Over the last few years I >> have personally dabbled in packaging for Gentoo, Fedora and Ubuntu. >> I'm far from an expert in any and have had to ask various questions >> every single time, but all of my problems have been quickly solved by >> other people more experienced than myself. There is also a huge amount >> of documentation available. This is the distributions core business - >> they like to package good things, and they are good at doing so. >> It is indeed an increase in difficulty of packaging (for the >> situations where developers will have a role in packaging, which will >> hopefully be less and less), but it also allows us to hand this off to >> other people (or at least access a huge amount of expertise), and it >> does represent an increase in the quality of our processes and a >> solution to some problems. > > I have a possible solution to this which would allow automatic > creation of rpms. I need to get time to sit down and see if this is > going to work which I don't think I'll get until late Oct at the > earliest but it should get us to a point where a Activity is tagged in > git and a while later a rpm in available in a repository. I'll post > more once I get the time to test my theory. If its proven it will > basically remove the arguement of "rpms are too hard for the > developers to make and they don't have the time to do so".
But we also have activity authors that don't want to go through the hassle of learning git :/ And even worse, we want people who are not yet able to create activities from scratch to do simple modifications to existing activities and redistribute them. Regards, Tomeu >> to summarise my thoughts: >> - Some of the outstanding problems are causing headaches for deployments >> - Some of the problems are just damn hard to solve >> - Some of the missing features are also damn hard to implement and are >> of no interest to deployments at this stage >> - I think we should focus on what we can do well and making things >> easy for deployments before trying to conquer the world > > Agreed. > > Regards, > Peter > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
