Openmoko Bug #1524: unable to uninstall kobodeluxe package through assassin

Openmoko Public Trac bugs at docs.openmoko.org
Fri Aug 29 00:43:09 CEST 2008


#1524: unable to uninstall kobodeluxe package through assassin
---------------------------+------------------------------------------------
    Reporter:  wendy_hung  |        Owner:  tick at openmoko.com
        Type:  defect      |       Status:  closed           
    Priority:  normal      |    Milestone:  Om2008.8         
   Component:  Installer   |      Version:                   
    Severity:  normal      |   Resolution:  worksforme       
    Keywords:              |    Blockedby:                   
Reproducible:              |     Blocking:                   
---------------------------+------------------------------------------------

Comment(by raster):

 blank icons - know about this. problem is... it's hard to solve - at least
 on the e/illume end. here is what happens:

 opkg installs a new .desktop file. the kernel sends a message to e
 (because it is listening for new files/changes/deleted files) saying a new
 file appeared. e now opens the file and looks at it. the .desktop file
 says "use icon X". illume waits 1 second then refreshes its application
 list widget - the problem is, the .desktop says to use icon X, BUT.. icon
 X isn't installed yet, because install takes so long. so a .desktop file
 that triggers the refresh refers to a file that it hasn't installed yet,
 and it takes so long toinstall that e gets bored of waiting (1 second) and
 refreshes anyway (there isn't any other mechanism with FDO/XDG etc. to
 trigger a refresh that i know of, so monitoring files is the way to go).

 now the big problem. we can make it 2 seconds, or 3 - then yu will
 complain that it is slow to refresh/show a new icon and we just ask for
 more bugs there. also if the package is very big - it may take longer, and
 so 2 or 3 seconds isn't enough, so we just play a cat and mouse game of
 the longest package install vs. time to wait. it's not a game you want to
 play.

 the other problem is - e looks for the icon, doesn't find it. this result
 is cached. searching for icons is very slow and expensive given the FDO
 standards, so to be sanely efficient you need to cache results. since the
 search failed - it has to cache that result for sanity. so a necessity of
 the standard used requires this.

 A solution is to make sure packages install icons before they install
 .desktops - they should install .desktops very much last. this solves all
 the issues that can turn up. otherwise we either cause performance
 problems by removing caches, adding special files that you touch in the
 applications dirs on end of install, have some magic tool to run to send
 dbus or whatever messages to all apps saying "now i'm finished installing"
 etc. either way you have to fiddle with packages and how they install
 stuff to really get this kind of thing fixed... and if you fiddle - the
 easy solution is simple install .desktop last :)

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/1524#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac


More information about the buglog mailing list