2009/7/28 Aleksey Lim <[email protected]>: > Proposal is not about storing all versions but about possibility of > storing not only one(last?) version and we can uninstall old versions > by removing entries from journal.
The journal can't delete activities that are installed by a package at /usr/share/activities, and I also think it is unlikely that our users would realise to do this even if it were possible. > There is no confusion, sugar is aware of what versions of particular > activity it has by using datastore.find() method, so user can run > `rpm update`, install any version by downloading .xo and sugar will run > last version(when user create new activity instance) or run particular > version(if activity object requires it). I was referring to confusion by deployments and those who are diagnosing bugs and soforth. > btw, activity can declare, in activity instance object, what activity > version(range) should be used with this particular instance object. Sounds like overcomplication. In response to your question on how I think it should be done, I feel that it's time to admit that packaging activities in this way is a mess. We should leave packaging and the related complications to the experts - packagers, and the package manager, and then we can stop wasting our time on it. For some kind of cross-distro package manager compatibility, someone recently raised the idea of PackageKit which seems well worth investigating and given its rapid development can probably be adapted to our needs. IOW I feel that the concept of sugar providing prepackaged binary activities should die. I think you would be a good person to work on this, and it is an interesting problem. > Well we can't say to activity developers that they must write > backwards-incompatible activities otherwise we won't host them on ASLO. > In that case using compatibility ranges of versions could fix problem > (w/o obliging developers write complicated code for > merge/support-backwards-incompatibility). It's nice to have the freedom to post whatever I want on ASLO and I'm not saying that should change. I'm free to write a buggy activity or one that isn't sugarized and post it on ASLO. Even though my activity is low quality and doesn't fit into the desktop, I'm welcome to post it. The consequence is that my activity probably won't be included in deployments, and I'll get some mails from testers making suggestions how I could improve it, and maybe even some patches. I'd say that this case is no different. > I like this idea only if all sugar users have 100% access to internet. > And they can run "upgrade my 0.82 to 0.84 from internet" process by one > click. But imho thats impossible in case of educational infrastructure > around of the world. The responsibility of keeping all machines in sync can be handled by the deployments, with the aid of good tools from Sugar/distro/OLPC. This is how it already works in the field. It's not your problem, but you could certainly help improve those tools and their concepts which seem a bit neglected right now. > imho activities are the same kind of objects - user should have chance > to edit/hack/share them like other sugar objects. Good point, but this seems to be beyond what sugar is capable of at the moment and raises more questions. Perhaps once there is the ability to modify your activity within sugar, the development activity could offer functionality to package up the modified version and save it in the journal. Exactly how the user could modify activities, how the user-modified activity would be saved on-disk alongside the original one, how they would be differentiated in the UI and how the user could switch between the two seems to be out of scope of this discussion -- or at least I can't see how it would be covered by your proposal. Daniel _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
