You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently repository status updates (new → active ↔ legacy) is not really tied to actual repository updates and thus not always correct. Improvement is needed, which may use the following logic: instead of deprecate_repositories+add_repositories in database_update_pre, compare list of repositories in the database with list of repositories from config. Added repositories are inserted with new status (and here we have chance to carefully choose unused ID and avoid problem with autoincremented smallint ID overflow), removed repositories are switched to legacy status. Then after updating packages, actual repositories are marked as active. This is also compatible with future per-repository updates.
Currently repository status updates (new → active ↔ legacy) is not really tied to actual repository updates and thus not always correct. Improvement is needed, which may use the following logic: instead of
deprecate_repositories
+add_repositories
indatabase_update_pre
, compare list of repositories in the database with list of repositories from config. Added repositories are inserted withnew
status (and here we have chance to carefully choose unused ID and avoid problem with autoincremented smallint ID overflow), removed repositories are switched tolegacy
status. Then after updating packages, actual repositories are marked asactive
. This is also compatible with future per-repository updates.While here, can also
metadata
field for Generalize repository metadata handling #735 (without removing existing columns yet for comatibility)last_updated
field for Introduce repository update periods #972repositories
table, as it currently resides in the separate table for no apparent reasonThe text was updated successfully, but these errors were encountered: