Add transition aware reverse rebuild selection

[aquilamacedo]

Add -transition_affected to select rebuild candidates by scanning parsed binary package Depends names from Packages indexes, mapping matching binaries back to source packages, and resolving source versions from Sources indexes.

Keep the existing reverse build dependency behavior as the default. In transition mode, still use the .changes file to inject the locally built .debs into sbuild with --extra-package. Warn when -direct-rdeps or -rdeps-depth are passed, since candidate selection in this mode does not use dose-ceve traversal.

Document how to choose anchored package name regexes from the runtime library package names involved in a transition, including how to adapt Ben Affected expressions when a tracker already exists

[aquilamacedo]

Hi @stapelberg, could you review this when you have a chance?

This adds a new opt-in option for library transition testing. I opened it after looking into the Salsa CI issue below: https://salsa.debian.org/salsa-ci-team/pipeline/-/work_items/571

[stapelberg]

Sorry, I’m very overloaded right now and won’t have time for this anytime soon. I suggest you just merge it or find a different reviewer.

[aquilamacedo]

no worries @stapelberg, thanks for the reply

I don't have merge rights for this repository, so I can't merge it myself

[ottok]

With Stapelberg's permission above I will try to step in here and review and merge. This is all anyway related to the Salsa CI reverse build job we are maintaining and improving.

[aquilamacedo]

With Stapelberg's permission above I will try to step in here and review and merge. This is all anyway related to the Salsa CI reverse build job we are maintaining and improving.

Nice @otto!! thanks a lot for stepping in :)

That makes sense, and your review would be very helpful here.

[ottok]

I am not able to spot any problems in this code. I did however not do a test run. How did you test and verify this is correct?

Side note: the .rst doc says -direct-rdeps and -rdeps-depth with a single dash, but some error messages say --direct-rdeps and --rdeps-depth with two dashes. I wish the parameters were consistently given with two dashes if they are full words/names. This is however not a regression of this commit, just something I noticed now..

[aquilamacedo]

Thanks for the review @ottok.

I added unit tests for the new selection path, covering source selection from parsed binary Depends, source deduplication, binary-to-source mapping, multiple Sources indexes, invalid regexes, and missing-source warnings

I also tested it manually against real archive metadata.

For poppler, I used the current transition tracker as reference:
https://release.debian.org/transitions/html/auto-poppler.html

-transition_affected '^(libpoppler-cpp3|libpoppler156|libpoppler-cpp2|libpoppler147)$'

This selected 22 source packages, matching the transition tracker source set. Running ratt without -transition_affected on the same .changes selected 331 reverse build-dependencies locally, which shows the old broad behavior.

for cmark, I used:

-transition_affected '^(libcmark0\.31\.2|libcmark0\.30\.2)$'

After enabling the same archive components locally, including contrib, this selected 11 source packages, also matching the tracker.

I also tested a pre-tracker style case with libass:

-transition_affected '^(libass9|libass10)$'

This selected 9 source packages. I compared that manually with grep-dctrl over the archive Packages file by finding binaries whose Depends mention libass9 and mapping them back to source packages, the source set matched exactly.

I verified the candidate selection against both tracker data and direct archive metadata, but did not run the actual sbuild rebuilds.

[aquilamacedo]

Side note: the .rst doc says -direct-rdeps and -rdeps-depth with a single dash, but some error messages say --direct-rdeps and --rdeps-depth with two dashes. I wish the parameters were consistently given with two dashes if they are full words/names. This is however not a regression of this commit, just something I noticed now..

I've just opened !38 to fix the inconsistency for "-" for now. In the future, I'll probably propose a separate change to consistently use "--" for all options.