One concrete use case for this feature would be installing toolforge-*-cli packages in a buildservice managed container. This is an idea that @Anomie and I have discussed as a potential partial solution for T356377: [toolforge] simplify calling the different toolforge apis from within the containers / T321919: Figure out and document how to call the Kubernetes API as your tool user from inside a pod.

Another would be installing packages from a tool maintainer managed PPA where things like custom builds of upstream projects could be staged for use. This could be a partial solution for T363028: Replace custom deployment with build service and job service.

T380108: ircservserv not detecting message sender when running behind ZNC v1.8.2 is another concrete use case where adding a PPA would enable installing newer software versions than are in the currently available apt repos.

In T363027#10485820, @bd808 wrote:

T380108: ircservserv not detecting message sender when running behind ZNC v1.8.2 is another concrete use case where adding a PPA would enable installing newer software versions than are in the currently available apt repos.

That one will also be sorted out with the upgrade to the ubuntu 24 runners though right?

In T363027#10485867, @dcaro wrote:

In T363027#10485820, @bd808 wrote:

T380108: ircservserv not detecting message sender when running behind ZNC v1.8.2 is another concrete use case where adding a PPA would enable installing newer software versions than are in the currently available apt repos.

That one will also be sorted out with the upgrade to the ubuntu 24 runners though right?

Yes, the particular problem of not having a new enough ZNC service available for installation could be solved multiple ways. In T380108#10329412 I imagined 3 concrete solutions: T380127: [builds-builder] Add support for Heroku's "24" builder stack based on Ubuntu 2024.04 noble, T363027: [builds-builder] Support adding repositories for Apt buildpack, or T363033: [builds-builder] Support using custom buildpacks. I actually think all three solutions would prove beneficial to the Toolforge community and not just the tools I am attempting to maintain.

I actually think all three solutions would prove beneficial to the Toolforge community and not just the tools I am attempting to maintain.

And that's great and appreciated, please keep bringing up ideas, though I hope you understand that not every idea can be implemented.

In T401075#11059135, @bd808 wrote:

We still have heroku/deb-packages 0.1.3 when using --use-latest-versions. The custom repo support was added to heroku/deb-packages 0.2.0.

A docker pull docker.io/heroku/builder:24 today has heroku/deb-packages 0.2.0.