Package: reprepro Version: 5.4.2-1 Severity: important Tags: upstream After upgrading from v5.3.1 to v5.4.2, the issue already described in https://github.com/ionos-cloud/reprepro/issues/9 arises despite having been fixed in the source code.
In more detail, if you create the repository database using v5.3.1, and then upgrade to v5.4.2 to manage multiple package versions, you cannot include multiple source packages that reference the same upstream package (*.orig.tar.gz/.xz file, same hash). The database operations will fail with the message BDB0696 Duplicate data items are not supported with sorted data Internal error of the underlying BerkeleyDB database: Within references.db subtable references at put: BDB0067 DB_KEYEXIST: Key/data pair already exists What is worse, the database is left in an inconsistent state given that the *.dsc and *.debian.tar.gz/.xz files are not removed from the database (nor from the pool) upon failure. One must then manually _removereference and _forget those files in order to recover consistency. This is the reason why I'm flagging this report as important. The fix that closed https://github.com/ionos-cloud/reprepro/issues/9 is actually in the source code already. I checked that references.db is correctly given the `DB_DUP` flag within the function database_opentable (database.c). Moreover, databases created using v5.4.2 are not subject to this issue. The problem must then lie in the migration from one database/version to the other. If I inspect references.db's header using `db_dump -p references.db`, I find the following: Created with v5.4.2: VERSION=3 format=print database=references type=btree duplicates=1 db_pagesize=4096 HEADER=END Created with v5.3.1, later updated with v5.4.2: VERSION=3 format=print database=references type=btree duplicates=1 dupsort=1 db_pagesize=4096 HEADER=END The `dupsort=1` flag is still present in the second references.db, despite it having been updated with v5.4.2. This could be what's causing the issue. If confirmed, the flag should be removed when the database is first modified using v5.4.2. Also, I believe that the version file in the database folder, which currently reads 5.3.1 3.3.0 bdb5.3.28 bdb5.3.0 should be upgraded as well to v5.4.2 upon successfull completion of the migration. Thanks, Giorgio
