> Anyway, I guess we'll have to wait until some real testing is done for > 8.2 in order to reach an agreement on what we should do with bundle > management.
I handle duplicates in the activity bundle registry by religiously using something like the 'sugar-forget-bundle' script. Besides, these days Joyride reboot is doing a good job of clearing no longer installed Activities from that registry. What I __wish__ for is that handling the bundle registry be made bulletproof. I've seen scripts work for user 'olpc', but fail for user 'root'. And the scripts have caniptions when they expect the xxx.activity directory, but it isn't found (or don't expect it, and it *is* found). Plus some calls to "dbus services" seem to fail for indirect reasons (e.g., net connection lost, or X not initialized). mikus (G1G1 user) p.s. In my opinion, the wiki has either too much or too little information regarding adding/removing bundles to one's running system. I can handle Activity bundle installs to /home/olpc/Activities (I use 'sugar-install-bundle'). If I have to replace an Activity bundle in /usr/share/sugar/activities, I just unzip the new version on top of the old one. If there is an obsolete bundle in /usr/share/activities/bundle-archive, I 'rm' it. p.p.s. Have not yet gotten around to trying out symbolic links to some Activities (so I can physically keep them on a removable device, and out of /home/olpc). But what I don't understand at all is how/why .xol bundles are supposed to be handled - I consider them to be "auxiliary", and not part of the "base system". [I don't want /home/olpc/Library taking up space in nand. Nor do I like nand space in /usr/share being taken up by 'libraries' -- I provide a "permanent" SD card for that very purpose.] _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
