Package: reprepro
Version: 5.4.2-1
Followup-For: Bug #1051537
Control: tags -1 patch
I noticed that reprepro doesn't automatically migrate the database if
needed after version upgrades. Instead, it raises an error and asks
the user to call one of the translate* commands. Therefore I would
propose to add one more such commands to fix this bug. I'm not sure
that this should be done without an increase of the major version,
but this is for the upstream developer to decide.
In attachment you will find one implementation of this proposal. It
works as follows:
- When an attempt is made to open the references.db file, reprepro
checks if the DUPSORT flag is set. If this is so, the database
needs to be upgraded, so reprepro exits with an error asking the
user to call the new 'translatelegacyreferences' command.
Notes:
The check is done by the database_openreferences function in
database.c. The function tries to open references.db with the DUP
flag and then reads the flags back. If DUPSORT is set, it means
that references.db was initially created with that flag, so we need
to recreate the file with DUP only to avoid the bug. Since reprepro
does not migrate databases on its own, we ask the user to do so
manually. Also, since not migrating the database risks leaving the
latter in an inconsistent state, we don't allow the user to access
references.db until they have migrated the database.
- The translatelegacyreferences command creates a new references.db
file with the DUP flag in place of DUPSORT. It then copies the
content of the old references.db file into the new one.
Notes:
translatelegacyreferences follows the logic of translatefilelists.
It is implemented by defining a new function
database_translate_legacy_references in database.c. The latter
first moves references.db to old.references.db, then copies the
content of the latter into the former, and finally it deletes
old.references.db. While database.c already defines a table_copy
function that copies between tables, that function discards
duplicates (it calls table_adduniqsizedrecord), so we define a new
table_copy_with_dup function that keeps them. table_copy_with_dup
does so by calling table_addrecord instead of
table_adduniqsizedrecord.
- Once references.db has been migrated, the first check passes and
the user is allowed to keep working on the database.
Some final notes:
- The patch does not currently upgrade the version file, but that's
trivially implemented.
- I tried to document the new command in the man page.
- The patch passes all tests except for test_database_upgrade in
multiversion.sh. This is to be expected: upgrades are no longer
automatic, but need to be manually performed using
translatelegacyreferences. Calling the latter before export in
test_database_upgrade makes the test pass.
