ci: support suite-aware extra repos

[simonbeaudoin0935]

Summary

Add support for package-repo-provided extra apt repositories during CI builds via an optional debian/extra-repositories.txt file.

Mechanism

build_package reads debian/extra-repositories.txt (if present) and forwards active entries to sbuild as --extra-repository.

Supported entry forms:

• Global entry (applies to all suites):
  • deb ...
• Suite-filtered entry:
  • [noble,questing,resolute] deb ...

Behavior:

• Suite filters are exact matches against the build suite
• unstable and sid are treated as equivalent for filter matching
• Empty lines and comment lines are ignored
• Active entries are de-duplicated
• Malformed bracketed entries fail fast
• Applies to all sbuild invocation paths in the action:
  • source/gbp path
  • prebuilt native path
  • prebuilt quilt path

Validation

Validated downstream with pkg-example using qcom-build-utils@development at commit fc9b2261e31f5e2cdb816e570698f96efb59d01f.

Workflow run:

• pkg-example build workflow run: https://github.com/qualcomm-linux/pkg-example/actions/runs/27319570199
• Inputs:
  • debian-ref=qcom/debian/latest
  • suite=noble
  • force-docker-build=true

Observed in logs:

• Extra repository file detected and loaded
• Loaded entry: deb [arch=arm64 trusted=yes] https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu noble main
• Build-Depends included python3.7-dev
• python3.7-dev and related packages were pulled from the configured PPA and build completed successfully

[basak-qcom]

Hi!

If an external build dependency is required to build, then that will be a hard blocker for release into the qli repository or upstreaming into Debian. We expect to package build dependencies into our repository first instead.

There's also an issue with possible code injection from external sources, so I'm not sure this is appropriate in principle at all. It also introduces potential for runtime binary dependencies that users' apt will not know how to fulfil. Before committing to this approach we should discuss further. @lool do you have an opinion here please?

If we do accept it, I think it should be permitted only in certain branch names, not everything, since that determines the target workspace and repository. This would touch areas of code I'm preparing in qualcomm-linux/debusine-action#41 (currently in progress).

[simonbeaudoin0935]

@jiaxshi @basak-qcom @lool

Jiaxing, please read Robie's comment above. Robie, Jiaxing is from the team that asked me to craft such feature.

[Whisper-chen]

Hi @basak-qcom.

Thank you very much for your feedback and for raising concerns about this approach.

However, ROS 2 is a widely used dependency in the robotics ecosystem. It is not included in the Debian or Ubuntu upstream repositories and is instead maintained via its own independent APT repository.

Without support for adding third-party repositories in PKG-REPO, it will be challenging to deliver robotics features effectively.

In addition, we need to identify and validate a practical solution to enable ROS 2 builds.

regard to the option "We expect to package build dependencies into our repository first instead". In practice, ROS 2 is designed to be consumed from its own APT repository. Re-packaging all dependencies internally is neither scalable nor sustainable and would make it difficult to track upstream updates and ensure compatibility.

[jiaxshi]

Thanks for your info @simonbeaudoin0935 @basak-qcom
My understanding is that the goal f the build utils infra is to ensure packages are released to upstream Debian/Ubuntu in a clean and controlled way.
However, for robotics segment/tech team, as @Whisper-chen mentioned, many of the features we delivery are built on top of Ubuntu and ROS(which is a 3rd party APT repo).
If adding extra repo into utils infra is not allowed, could you share the guidance for tech team to integrate 3rd party apt repos?
For example:

• Is there a preferred mechanism to manage external dependencies?
• Are there any approved patterns or exceptions for cases like ROS or vendor-specific repos?
• Or should these dependencies be handled outside of the utils infrastructure?

Appreciate your guidance so we can align with the intended design.

[lool]

Hi @jiaxshi, you should eventually be able to provide extra repositories and build ROS style packages; this is not our highest priority, but the infrastructure should be able to do that.

What you'll need are 1) a definition of your target build environments (which Ubuntu series, which overlay APT repositories – likely the ROS one, plan for Debian), 2) a definition of your build interface (sbuild ok? or some ROS specific one), 3) a definition of your source to upload strategy – github + gbp + branch name convention?

This will likely take a few iterations over some kind of spec.