On Mon, Nov 25, 2019 at 03:21:47PM +0100, Ivo De Decker wrote: > The root cause is that items that migrate due to the easy hint, are tried > again during the main run. This started with commit > 6174d2c3f9590eba90f9c6dd613a553edd3a80e6 > > After this commit, the 'selected' items are no longer removed from > self.upgrade_me, because the items are represented by different objects in > both cases: > > self.upgrade_me = [x for x in self.upgrade_me if x not in set(selected)] > https://salsa.debian.org/release-team/britney2/blob/master/britney.py#L1113 > > Example (from test takeover-removal-easy): both contain 'linux/5.3-1' and > '-linux-latest/10', but the objects are different: > > selected: [<britney2.migrationitem.MigrationItem object at 0x7f09d578ab38>, > <britney2.migrationitem.MigrationItem object at 0x7f09d578aba8>] > upgrade_me: [<britney2.migrationitem.MigrationItem object at 0x7f09d578ae48>, > <britney2.migrationitem.MigrationItem object at 0x7f09d578a9e8>] > > > The commit mentioned above might have caused similar issues elsewhere in the > code. > > Note that, for test takeover-removal-easy, not only '-linux-latest/10' is > tried again, but also 'linux/5.3-1'. For the latter, all binaries are removed > and added again when it 'migrates' for the second time. There are probably > corner cases where this would also cause unwanted behaviour.
The root cause of the issue is that the MigrationItem object can be versioned or unversioned. When comparing a versioned to an unversioned item from the same source, they match, however, the hashing function will return a different value. So whenever a set is used, this goes wrong. The way to fix this is to make all (relevant) migrationitems versioned and don't allow unversioned migration items to be hashed. Ivo
