ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

How to disable package builds for ARM64?

You're right that to disable them on a specific platform you need to blacklist the packages. The question you link to tells you exactly how to do that.

The reason for the blacklist being where it is is because of the separation of concerns. All of the artifacts which are generated up until the binary jobs are architecture independent and at the point that we generate the source debs there is nothing architecture dependent. And at that point we're only using the debian packages and the debian packaging pipeline and there's nothing directly connected to the original repository anymore. Each repository may become N packages, and after bloom has completed the packages are no longer associated with the repository they're independent. Furthermore, grouping at the repository level makes the assumption that all packages in the repository are similarly compatible or incompatible with an architecture. It could easily be that a repository has an architecture independent package with messages and configuration files, and maybe launch files which is next to the package with an architecture dependent library.

We could embed the metadata into the package.xml or somewhere else in the repository and have the buildfarm keep the association and look it up that way. However that requires the upstream package maintainer to know and care about any and all architectures. With the current system it's quite possible that a company may want to turn on an alternative architecture that isn't on the main buildfarm (say i386 that we dropped recently) It doesn't make sense to require them to submit upstream patches with flags to the source repositories for the projects versus configuring their specific buildfarm's instructions. Furthermore, there may be other dimensions of the build environment that effects buildability of the package. For example you may choose to build specifically for the older RaspberryPi with it's odd hybrid of arm architectures. And again this is not something you necessarily want to bother the upstream maintainers with unless you want to submit a patch which extends the compatibility.