> Also, on a mobile device, it's much more likely that the battery runs > out, or drops out (if user is a bit thoughtless). If this happens when > you're running dist-upgrade, you've bricked your device. Well, not really.. you can still flash it. Or reboot from memory card and continue thru chroot or.. Also before such update the battery level could be verified. If the updates come out 2-3 times a year, the update could be done from memorycard so all the prelinked files would be updated. Also niced prelink afterwards could take care of the rest, thus prelinking also user installed software. (is it done now?) I understand there is much more probable that the update doesn't run smoothly when people have had time to f**k up the system more or less freely. This creates many possibilities that the base system just doesn't run after update like it should do. Flashing is easy way to bypass this problem thus causing other inconviniences But what comes to developers and consumers wanting convinience.. I have to say reinstalling all the software is way too time consuming even when automated. Of course when API's change and versions jump like 2.1 to 3.0 you just need to reinstall everything but when changes are smaller "apt-get upgrade" should do the trick. I think installing the base system from debs would take less time than installing all the programs I currently have installed. > Except maybe for the time taken to do backup & restore, re-flashing > the device is both faster and easier than dist-upgrade. The backup & > restore could be improved somewhat, especially in regards to application > installer though. Automatic restoring of packages after reflashing > could be risky though. I have made small scripts for these nasty reflashing situations. If there is intrest I could clean up the scripts and release. I think there might be.. maybe I'll clean them anyways. Scripts aren't be anything nice and smooth they just "works for me". The way it works is that I first run normal backup, then backup /home and /etc/apt/ and finally run "dpkg --get-selections > selections.txt" to get package states and move all of this to the memorycard. I also have saved all manually downloaded packages on the memorycard. After reflash I return the stuff with small automated script run when I install an deb from memorycard. I have maemo-launcher kept back so running "dpkg --set-selections < selections.txt; apt-get update; apt-get upgrade" goes more or less smoothly if there isn't too many packages to install (space runs out). Only those dialogs asking for location in the menu stop the automation. Manually installed packages I have installed rather ugly way "dpkg -i *deb; apt-get -f install" (latter is to solve dependencies with libraries). Actual list of user installed programs is solvable (exclude base system and user installed dependencies) If (when?) repositories would be just one central repository then after flash and restore of backup the repository url could just be changed: "deb http://repository.maemo.org/ 3.2" would change to "deb http://repository.maemo.org/ 3.3". And by running the list of software installed before thru apt-get we would have updated system running. Now with the central repository all the existing programs could be compiled in the darkness for the new system/OS. And when ever the always mysterious corporation would release, there would be programs waiting unlike now with the 770 to n800 change or earlier API updates. -- VRe :: http://iki.fi/vre
