[sugar] Avoid duplicates in the bundle registry

[Mikus Grinbergs]

> 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.]