Re: Activity packaging
On Wed, 04 Aug 2010 20:05:06 +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. I think that's a little different. Fedora allowed an unprivileged user to install a package, but giving the package full privileges. For 0sugar, I assume, the user is fully privileged (it's their machine); it's the package that should be restricted, not the user. This distinction has caused a lot of confusion in the past, and I've now added a section to http://0install.net/injector-security.html to try and clarify it. I've also added a demonstration of using 0install for sandboxing, showing how sandboxed processes can still share libraries (which doesn't happen if you just create lots of separate RPM databases): http://0install.net/ebox.html Hope that helps, -- Dr Thomas Leonard http://0install.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Wed, Aug 04, 2010 at 08:05:06PM +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Thats right, and all PackageKit benefits will be reused within 0sugar/0install (but mostly for non-sugar dependencies, it will be possible to reuse native packages for sugar application as well but see below). But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Sun, Aug 08, 2010 at 07:18:51AM -0700, Jon Nettleton wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. Well, I thought also about vcs but came to decision that it sounds like misusing of vcs: * vcs is all about sources (storing binaries is possible but is misusing), * all sugar related code will be shared only in sources, which is not bad in general (especially as an option) but sounds overkill for binary-based activities * all dependencies should be stored in vcs and deployed via vcs as well (otherwise system should be not pure vcs and will look pretty ugly) Also there is no need in storing results of experiments in vcs at all, e.g., doer just tweaks his local code and let 0sugar share it w/o commiting to vcs server(which should be used to fetch sources on client side), supporting per doer vcs servers would sound pretty overkill. Some kind of binding vcs repos with packaging/distribution stuff is possible and afaik many GNU/Linux distribution do packaging from, e.g., git repos (we can do similar things on our OBS), but they don't mix vcs and distribution. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On 8 Aug 2010, at 15:18, Jon Nettleton jon.nettle...@gmail.com wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. FWIW this is certainly the way I've worked on activities in Sugar for some time now, my ~/Activities is mainly git clones. --Gary -Jon ___ olpc mailing list o...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity packaging
On Tue, Jul 6, 2010 at 6:50 PM, John Gilmore g...@toad.com wrote: I think you are missing an important requirement: installation without elevated permissions. Enhancing deb or rpm to be able to do this would be a win all around. A nonroot install would install under one's home directory, if either the package was marked as tested for homedir installation, or the user provided an override. The underlying OS would have to ship user PATH and LD_LIBRARY_PATH defaults to include $HOME/bin and $HOME/lib. A package database would exist under $HOME as well. Read-only access to the global package database would allow the local package to check dependencies, etc. It may be useful to define a standard programming convention for a package to readily find its control files and data files (either in /etc and /usr/lib, or in $HOME/.something, etc). Ideally it should be possible to ask that a package be installed under any particular directory, allowing users to install several different versions of a package and run them from different places. This would let users run multiple applications which depend on particular versions of another package (e.g. python), while allowing the system default to be upgraded to the latest (incompatible) version. rpm can already do that. It can relocate the package install location. I'd argue for adding this to deb, partly because Fedora at one point indicated a willingness to move from rpm/yum to deb/apt whenever someone does the work, whereas Debian and Ubuntu seem satisfied with deb and apt. But that would be a longer road for OLPC and other existing Fedora users. I very much doubt that would ever happen. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Rainbow, on the other hand, has seen a major new release, feature development that spurred new work in general Linux sandboxing, and is now available in more distributions than ever before thanks to dedicated support by folks like Luke, Sascha, and Jonas. Finally, if rainbow itself now receives little day-to-day attention, this is because it mostly does what its authors require and it does it well enough not to require their continued hand-holding. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
Aleksey wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software... rainbow should be more then essential requirement. Let's be clear: the actual requirement is for something more like safety or isolation. Rainbow is merely one of several reasonable approaches -- and competition and interoperability would be no bad thing here. Michael P.S. - Several other isolation shells that might be worth thinking about, if only to better understand the tradeoffs that rainbow makes, are briefly described at http://sandboxing.org P.P.S. - Also, either way, thanks for your encouragement. :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 7, 2010 at 2:16 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Rainbow, on the other hand, has seen a major new release, feature development that spurred new work in general Linux sandboxing, and is now available in more distributions than ever before thanks to dedicated support by folks like Luke, Sascha, and Jonas. Finally, if rainbow itself now receives little day-to-day attention, this is because it mostly does what its authors require and it does it well enough not to require their continued hand-holding. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. I took some time to read up on 0install -- very impressive technology, good work. I agree with Michael that this (userland installs) is the direction Sugar should be pursuing. With rainbow (or other sandbox) integration, this would accomplish all of the original goals with a much more robust packaging and dependency system than the .xo bundle. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Activity packaging
On Mon, 2010-07-05 at 16:20 +0200, Tomeu Vizoso wrote: Sorry about the confusion, these questions were about the move from xo bundles to packages :( Ah! Communication FAIL! :) Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. To obtain (2) and (7), we might want to wrap the native packages with a distro-neutral meta-format, similar to the current activity.info files. I don't know the details yet, but I guess this is pretty much what Aleksey is doing with his 0sugar redesign. I think switching to a native package format is essential: currently, both the Fedora and Ubuntu teams are spending a lot of time to re-packaging just a few activities, resulting in duplicated effort and increased time-to-market for activities. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity packaging
On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. --Ben P.S. This cross-posting is getting ridiculous. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity packaging
On Tue, Jul 6, 2010 at 1:50 PM, John Gilmore g...@toad.com wrote: I think you are missing an important requirement: installation without elevated permissions. Enhancing deb or rpm to be able to do this would be a win all around. Yes, it's been in the To Do list for dpkg and rpm for as long as I've been using Linux -- I asked about this for rpms in '98. Sadly, the rate of development around rpm and dpkg is... well... slow... rpm has a leg up, anyway, in that it has (limited? buggy?) support for relocatable rpms. It would be amazing for the overall health of Linux distros if someone took this on and worked on it all the way to getting it done and merged. Packages (and maint scripts) would need to be updated/adapted to support this, and of course it's not appropriate for all packages. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 06, 2010 at 11:51:00AM -0400, Bernie Innocenti wrote: On Mon, 2010-07-05 at 16:20 +0200, Tomeu Vizoso wrote: Sorry about the confusion, these questions were about the move from xo bundles to packages :( Ah! Communication FAIL! :) Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. To obtain (2) and (7), we might want to wrap the native packages with a distro-neutral meta-format, similar to the current activity.info files. I don't know the details yet, but I guess this is pretty much what Aleksey is doing with his 0sugar redesign. Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance i.e. for activity developer, process should look like pretty straight forward, everything what he needs is a spec file. Spec file is not like regular activity.info (some kind of metadata file that is used in runtime) but a regular spec file like .spec in rpm. Some examples of real (but for now only built only for 0install) http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_library http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Vala_library and how it will look like for activities http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_activity The milestones I'm planing are: * Having just 0sugar.info spec file (and 0distro build time dependency on obs), build native packages on bunch of rpm and deb based distros on OBS. I'm planing to have rpm and deb packages for Sucrose, Polyol, GC, OOo4Kids built from only 0sugar.info spec files in two weeks * Having just 0sugar.info and 0sugar tool, distribute homemade blobs (already works) and blobs built on OBS via 0install * merge all things together and make it useful within sugar - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core - switch from bundle_id identification to http urls for activities, (at some point it sounds like urls for microformat updates) it could be really useful if user on any sugar box could run activity just by mentioning its url * new UI, how it could look like with new packaging infrastructure So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. The rest of steps could be implemented in parallel manner. I think switching to a native package format is essential: currently, both the Fedora and Ubuntu teams are spending a lot of time to re-packaging just a few activities, resulting in duplicated effort and increased time-to-market for activities. just an OBS feature that could be used as is if most of activities will accessible from obs http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Use_Cases#Per_user_Sugar_on_a_stick -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity packaging
On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. XO and SoaS distributions are configured for sudo with no password. Rainbow has been bit-rotting for the past 2 years and nobody volunteered to work on it. The bottom line is that *nowadays*, any activity can escalate root privileges. Before someone screams in horror, consider this: the only valuable data on the laptop belongs to user olpc. A non-privileged account can already effectively do anything that a spammer would like to do. Even in a Rainbow-enabled environment, privileged vs unprivileged installation isn't by itself the source of security issues. Packages could easily be checked to ensure that all bundled files are within a specific path, like we currently do with the zip files. Post-install scriptlets can be disabled. Even with these limitations, a native packaging system is still years ahead of us in terms of robustness and feature-completeness. P.S. This cross-posting is getting ridiculous. Mikus keeps moving this thread to other lists because he won't subscribe to sugar-devel. (why?? ask him). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Tue, 2010-07-06 at 19:56 +, Aleksey Lim wrote: Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance Will it also remove the need to ship fat bundles, as we do now? I mean, will it produce separate packages for each architecture/os or just one large package with many binaries in it? I tend to prefer the first way, like rpm and deb do. - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core Wouldn't PackageKit be a perfect match for this? So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. It's an amazing piece of work, Aleksey!! Considering that you're tackling on the hardest problem in the Sugar universe, I'm very impressed by the progress you've made in such a short amount of time. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 06, 2010 at 05:59:04PM -0400, Bernie Innocenti wrote: On Tue, 2010-07-06 at 19:56 +, Aleksey Lim wrote: Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance Will it also remove the need to ship fat bundles, as we do now? I mean, will it produce separate packages for each architecture/os or just one large package with many binaries in it? I tend to prefer the first way, like rpm and deb do. There is no any bundles in core design i.e. if you are talking about fat bundles we are talking about distribution method, in my mind such distribution methods could be: * via distro repos on obs(or other build farm), users attach these repos * via 0install, user just type sugar-activity/0lauch http-url to start activity or any software * for sneakernet, 0sugar tool could generate bundles like ./setup.py dist_xo does, imho there is not huge need in having smart/fat bundles like I tried to to with 0installed bundles; but anyway later practice will make it more clear - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core Wouldn't PackageKit be a perfect match for this? Firstly, 0install already can install native packages via PackageKit and secondly (keeping in mind your reply to Benjamin), talking about *only* native packages we loose one simple and core-for-sugar thing, any sugar user should be, at the end, a doer. For example, if we have TuxPaint activity and many doers are experimenting (change C code and compile) with it, what can do a person, who decides to try all these TuxPaint activities, having native packages as only distribution method? ask all doers use the same repo (sounds useless); attach repos per doer (conflicts); handle all issues by himself (not useful as well). With having 0install (which is already exists and works) as engine, we handle these issues automatically. Using 0install doesn't mean that everything is ok with 0install from sugar pov, e.g. one of core sugar workflows when user need only place activity to ~/Activities to make it useful is absent in 0install (it designed as regular packaging system e.g. there is no need in changing some software in /usr/lib). So, 0install is required later hacking but it effectively solve last of packaging issues - how to *launch*(not install) arbitrary activity in heterogeneous environment. So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. It's an amazing piece of work, Aleksey!! Considering that you're tackling on the hardest problem in the Sugar universe, I'm very impressed by the progress you've made in such a short amount of time. Well, not so short amount of time, my first commit to jhconvert (my first experience in meta packaging) was Fri Dec 05 01:29:55 + 2008 -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
