Item144: Installer doesn't handle dependency loops very well

This morning Michael wanted to update the Nat* suite on nextwiki.org, and it again, reported success, but did not install the new versions. interestingly, it did install files - the ownerships changed (from www:www to www:wheel), but the dates did not.

I eventually tried deleting the NatSkinPlugin.tgz and suddenly it not only reported success, but actually did so using the new version of the files...

so the bug is.. configure needs to make sure that the tgz it is unarchiving is the file it intends to unarchive - ie, use the md5, check file size&date, and other validations.

There needs to be no doubt that what it installs is the version it thinks - else a user may well lose customisations that are premitted by a later fix.

(eeek )

-- SvenDowideit - 11 Nov 2008 - 23:27

The problem turned out to be in dependency resolution. If A depends on B, then it would download B and install it. If B depends on A, it would recursively try to install it, without knowing it was mid-install. If B had previously been installed, the dependency on A would have left an archive for A on disc. This new install of B would see that archive, and try to re-use it to install A, overwriting the files just installed. Temporarily resolved by telling the sub-install to never use files from disc, but this sort of dependency loop needs to be detected and broken.

Leaving this open (dropped to Normal and with a more meaningful headline) because it ought to be fixed.

-- CrawfordCurrie - 13 Nov 2008 - 18:52

I believe that the dependency resolution loop might be fixed in 1.1. Any chance you could try it out?

-- GeorgeClark - 22 Aug 2010

I'm going to presume its fixed, else its going to be waiting along time for me to replicate - f.o doesn't use NatSkin anymore..

-- SvenDowideit - 14 Sep 2010