#7713 NORM 8.2.0 (: Inconsitent behavior for activity installation

[Zarro Boogs per Child]

#7713: Inconsitent behavior for activity installation
---------------------------+------------------------------------------------
   Reporter:  erikos       |       Owner:  marco               
       Type:  defect       |      Status:  new                 
   Priority:  normal       |   Milestone:  8.2.0 (was Update.2)
  Component:  sugar        |     Version:  Git as of bug date  
 Resolution:               |    Keywords:  8.2.0:?             
Next_action:  communicate  |    Verified:  0                   
  Blockedby:               |    Blocking:                      
---------------------------+------------------------------------------------
Changes (by Eben):

 * cc: homunq (added)
  * keywords:  => 8.2.0:?
  * next_action:  diagnose => communicate


Comment:

 Replying to [ticket:7713 erikos]:
 > Steps to reproduce:
 >
 > Download an activity that is already installed (e.g. Log9 is installed
 and you download Log10).
 >
 > a) When the download has finished go to the activity list and check if
 the bundle is upgraded (it will still be the old version)

 Bad!

 > a) we only install a bundle that is not installed already:
 http://dev.laptop.org/git?p=journal-
 activity;a=blob;f=journalactivity.py;h=f531e0fe860a46a4483d41bbb26a586794f888ad;hb=HEAD#l264
 >
 > b) we upgrade a bundle when it is already installed:
 http://dev.laptop.org/git?p=sugar-
 toolkit;a=blob;f=src/sugar/datastore/datastore.py;h=b88a8775a962eb4b06fb740bc7616c2c711f9f24;hb=HEAD#l155

 I'm not sure I agree with the implied definitions of "upgrade" and
 "install" in these cases (though I agree you use them appropriately with
 regard to the current, inconsistent behavior).  Clearly case (a) should
 also be considered an "upgrade" of an existing activity, and we should
 simply install any bundle of any version  number (including the ''same''
 version).  I see no reason to attempt to optimize this, even when the
 version numbers match.

 I think this actually relates to a recent patch from homunq. Was that the
 same issue?

 It seems that, especially in the face of potential incompatibilities
 between old activities and the new OS, we should make sure that these
 upgrade paths all work smoothly.  Furthermore, it seems that simply
 removing the condition which checks to see if the activity is already
 installed should be an easy fix.

-- 
Ticket URL: <http://dev.laptop.org/ticket/7713#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system