So...why do some installed apps stop the PR1.2 upd...

Question

I read the long PR1.2 thread when I started having trouble trying to get PR1.2 to load on my machine : OTA wouldn't work ("update must be run thru a PC link") and PC-connected upgrade got half way through and crashed repeatedly, thankfully without turning my N900 into a paperweight.
The long PR1.2 thread contains various bits of personalised help from cpitchford advising individuals to uninstall various games and other apps from their phones.  Then voila! the PR1.2 upgrade works.  In one of those posts I read that Tuxdriver (or some such sillily named game) was a problem, so I uninstalled that lousy app from my N900 and my OTA upload was suddenly enabled and it installed.  I now run PR1.2 on my N900. :-)
I am left puzzled though.  How can the N900 (or rather Nokia) allow a software app to accidentally mess up the operating system so badly that upgrades give misleading messages (or no messages) and fail to install?  How come so many apps cause this problem?  Why doesn't Nokia publish this information or get the update processes to report which apps are causing the problems?  There must be thousands of N900 users who can't update to PR1.2, get no meaningful error message at all,  don't read the board here, and so don't know that one of their installed games is the cause of the problem.  This all seems so amateurish on Nokia's behalf, to me at least.
cpitchford could you explain the reason why / how some installed games stops PR1.2 installing.  I'm curious.
Thanks
H

Answer 1

hey hey!!
Ok its not Nokia's fault.. or at least I don't think it is.. not totally convinced but here goes.
DPKG the packaging system works on dependencies.. a package can only be installed if its dependency packages are install already..
apt is a tool to do this resolution for you.. when you want blah installed it makes sure all of blahs dependencies are installed first.. and infact it makes sure that the dependencies of blah's dependencies are install and so on.. Generally it is pretty good..
Now in its simplest form, dependencies just specify a package name
blah requires moo
Easy.. any version of moo must be installed before blah can be installed..
But dpkg lets you get more creative and specify versions too.. so for example
blah requires moo (>> 1.5)
means that blah requires at least version 1.5 of moo before it can be installed..
BUT!!!!!! it can also specify an exact package version
blah requires moo (=1.5)
So.. what happens if I later try to install moo version 1.6? I can't.. apt won't let me because it would break blah.. (if you're following up to this point.. grand!)
Lets look at a particular problem.. gltron
gltron requires libgles1
libgles1 requires libgles1-sgx-img
libgles1-sgx-img requires opengles-sgx-img-common (=0.20091104.6.1+0m5)
Now, gltron requires lots of packages.. but this particular branch if you like causes the problem.. if we follow the dependencies down we see that libgles1-sgx-img requires a very specific version of the package opengles-sgx-img-common
PR1.1.1 : 0.20091104.6.1+0m5
PR1.2:    0.20091104.34+0m5
So PR1.2 wants to upgrade opengles-sgx-img-common to a newer version.. which would break the dependency for libgles1-sgx-img
So, removing GLtron and infact any package that if you follow its dependencies down you hit libgles1-sgx-img fixes most problems
I wrote a script that identifies a tree of packages.. it tells you whats at the top (ie gltron) and what dependency at the bottom is a) fixed in version number and b) going to be upgraded when PR1.2 is installed
So, the output in this example would be
gltron broken by libgles1-sgx-img which needs opengles-sgx-img-common
Whoever is responsible for that package made the mistake.. Either of not providing a new version of libgles1-sgx-img that is compatible with PR1.2's openglex-sgx-img-common package OR by setting a precise version and not something like
(=0.20091104)
which I think would've been safe
It is a bit pants that the error messages are few and unhelpful though..but it is an easy thing to fix if you know EXACTLY what you're looking for
Lots of people said "I only had 50meg free so I kept removing packages until it worked"
It wasn't clearing space that fixed it (as I only had 42 meg free when I installed I think) it was that they'd removed the package that freed the dependency collision
I hope that makes it clear (as mud?!)