21

This is a great concept, but the increased complexity of managing heterogeneous systems causes significantly increased labor/time to support it which can potentially offset any cost savings for the compute. And depending on the mechanism of delivery there’s significant trust and security complexities too. Not to mention bandwidth costs, latency concerns, uptime monitoring too.

We’re working really hard to get away from this process. You’ll note that there’s been no new packages added there recently that aren’t directly developed by the core team, and those are mostly updates of existing packages.

If someone sets up a PPA for a package, they then need to also setup a build for every other potentially supported platform and arch combination. REP 2000 -- ROS 2 Releases and Target Platforms (ROS.org) I don’t think that we want to limit Nav2 to only run on specific Ubuntu arches in a PPA. And there’s also significant issues with reproducibiliity and trust for these packages too. What happens in the case of a security vulnerability. We would need to be able to respond and have pathways to patch and rebuild. We’ve had issues in the past when PPA maintainers were unavailable and we had to look at creating our own copies of it to reproduce with a fixed version. And suddenly it looks like we’re effectively recreating what we’re already doing on the ROS Buildfarm, but with more effort for a subset of platforms.