Bug#945471: britney crashes when trying removal multiple times
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
Reply to: