Package: reprepro Version: 5.4.6-2 Followup-For: Bug #1095493 X-Debbugs-Cc: noisyc...@tutanota.com
I got the same error after updating a 'mesa-asahi' package. After running translatelegacyreferences [1] and doing the update, my packagenames.db contains a single item, [(b'mesa-asahi\x00', b'mesa-asahi|25.1.0~git20250221.67b507f-1\x00')] while those in my packages.db are two, with keys [b'mesa-asahi\x00', b'mesa-asahi|25.1.0~git20250221.67b507f-1\x00'] (these were obtained using the berkeleydb python package). This is wrong: packagenames.db is a secondary indices database for packages.db, so it must contain one and only one item for each key in packages.db (with the value equal to the key). This mismatch is the error we are observing. Using -VVV it seems that database_translate_legacy_packages was never called. I think this is because database_openpackages calls database_table_secondary with the DB_CREATE flag before calling database_translate_legacy_packages. In turn, database_table_secondary calls database_opentable *for packagenames.db* with the DB_CREATE flag, which creates the database. So when database_openpackages then must decide whether to call database_translate_legacy_packages, it finds packagenames.db and thinks it must not. It then proceeds to update packagenames.db and packages.db without doing the migration, which leaves the database in an inconsistent state (see above). [1] For full disclosure, I am the author of translatelegacyreferences, which I submitted under a different name (my real one). I checked that command doesn't do anything unintended, other than changing the DUP flags as documented. In particular, it doesn't touch neither packages.db nor packagenames.db, where this bug originates.
