debian/sid branch incorrect when multiple versions are published

[Robie Basak]

It is possible for there to be multiple versions of a source package published in sid at the same time. For example, currently dbus has both 1.14.8-2~deb12u1 and 1.14.8-2 published in apt Sources for sid.

In this case, the Launchpad API expresses both source_package_publishing_history entries in the Published state at once for the same suite.

Users would expect debian/sid to point to 1.14.8-2 and not 1.14.8-2~deb12u1 in the example above. However, currently the importer algorithm results in the source_package_publishing_history entry with the most recent date_created field being the one pointed to, which in this example is 1.14.8-2~deb12u1.

When a newer version is published in sid, the branch pointer will be force-pushed, which users will also not expect.

This affects the branch pointers only. The commit graph is unaffected.

See https://irclogs.ubuntu.com/2023/07/20/%23ubuntu-devel.html#t11:31 for more background and discussion.

[Robie Basak (racb)]

Suggested resolution:

Adjust the importer algorithm so that the regular suite-based unapplied branch pointers are not moved incrementally as successive publications in Launchpad are imported. Instead, they will all be updated together at the end of an import for the entire source package at once as follows.

For all known suites, run getPublishedSources() against that distro_series and pocket, take the highest version, and set the branch pointer to that. Note: remember "exact_match=True"!

It would mean one more iteration per pocket every six months. Perhaps I could add an importer CLI option to ignore suites older than some date, so that regular production runs could skip EOL suites.

It'll also be necessary to make sure nothing else in the importer relies on these branch pointers being present at the earlier stage.

It shouldn't be very difficult to run the new algorithm against all existing repositories to see which branch pointers would change first.

[Robie Basak (racb)]

This might also have an impact on bug 1852389, because looking for Published entries only implies that deletions _would_ be followed.

[Robie Basak (racb)]

I wonder if there's any consideration for reimports required. At a later point, we will no longer know which reimport a source_packaging_publishing_history corresponds to.