Improve autoware-deb-package Customizability

[jerry73204]

The discussion was raised in the OpenAD kit WG meeting on Aug 28 that it comes the colcon2deb packaging tool from NTU. The colcon2deb runs in local Docker containers, while the official autoware-deb-packages runs on GitHub Workflow. Check the Claude Code-generated report to learn about their difference.

colcon2deb was designed to provide platform-specific customization in mind, as it was created for the an AGX Orin-powered AutoSDV vehicle. I list features from colcon2deb that can be adopted to improve customizability on the official buildfarm.

Dependency injection

It happens that amd64 Ubuntu 22.04 and Jetson Linux ship different CUDA versions. The Autoware 2025.02 requires CUDA 12.3, while the Jetson Linux provides 12.2 cannot be upgraded manually. The shlib.local is used to inject different CUDA deps for amd64 and jetson.

Custom Build Image Support & Out-of-rosdep Dependencies

There are cases that the dep cannot be specified in package.xml and is required for specialized hardware. On Jetson Linux, the nvidia-l4t-dla-compiler is required to build packages requiring CUDA. Otherwise, the build will fail. The customized Dockerfile was created for AGX Orin to workaround this.

Fix failing commands from bloom-generate

Both colcon2deb and autoware-deb-packages use bloom-generate to create Debian control/rules. It generates failing commands sometimes. One example is that autoware_lidar_centerpoint can fail with "symbol `fatbinData' is already defined" error using default commands. The patch was added to work around.

[esteve]

@jerry73204 thanks for creating this discussion. Did you create the text for this discussion with AI as well? I'm asking because there are some inaccuracies and errors here and in the report that Claude generated.

For example, in "Fix failing commands from bloom-generate", the error mentioned symbol 'fatbinData' is already defined is not because of bloom-generate, but because Debian (and Ubuntu) by default enable link time optimization in their compilers, but CUDA does not support that, hence the -fno-lto flag. We fixed that in Autoware by making sure that downstream dependencies of autoware_cuda_dependency_meta pass the -fno-lto flag to the compiler (see autowarefoundation/autoware_universe#11115)

In any case the Claude-generated report has many other inaccuracies, I'd prefer a human-generated report to avoid these errors.

It's not clear to me what the goal of this discussion is as stated here, correct me if I'm wrong, but I was under the impression from today's meeting that we wanted to see if there was any overlap and if there was anything in autoware-deb-packages missing that your team at NTU needed and therefore other users may need as well, etc. but the goals stated in the text are already solved in autoware-deb-packages

[jerry73204]

I wrote this post myself, not AI, as you can see there are grammar errors in my post.

The fatbinData was an issue for us and we had to workaround this before it's fixed in the upstream (See our fix in March). There are reasons that we pin down a version (2025.02) and provide stable binary release for other members. It takes time to maintain the software on a fleet of non-Internet-connected vehicles. We also have to provide consistent functionalities for our partners. That's why the issue remains and we have to address it during the packaging stage.

I believe the similar issue arises in many other ecosystems that the developer and packager run in different cycles. For example, packagers on AUR can provide patch releases. As the Autoware will be deployed to various kinds of vehicles, I believe the need for modified/Autoware builds is real. Per our discussion, we can focus on two things that could benefit us:

• Enable more customizability in the buildfarm to satisfy the needs for users using their modified Autoware for specific platforms,
• or provide stable release cycle serving different versions and platforms.

[esteve]

@jerry73204 thanks for taking the time to create the discussion, I didn't mean any disrespect, I asked because you mentioned you generated the report with Claude, apologies if I offended you.

Enable more customizability in the buildfarm to satisfy the needs for users using their modified Autoware for specific platforms

Correct me if I'm wrong, but the issue here is basically the need for adding dependencies outside rosdep, right? There are two ways of doing that with autoware-deb-packages:

• Add custom rosdep rules. We do that for pacmod_interface (see https://github.com/autowarefoundation/autoware-deb-packages/blob/main/.github/workflows/generate-deb-packages-aws-reusable.yaml#L86)
• Add the Debian packages directly as part of the sbuild chroot. We do that for CUDA (see https://github.com/autowarefoundation/autoware-deb-packages/blob/update-release/core_1.3.0/.github/workflows/generate-deb-packages-aws-reusable.yaml#L88)

or provide stable release cycle serving different versions and platforms.

We have builds for Autoware 1.3.0 and for nightly snapshots (about 3 times a week), is that frequency enough for your use case?

One of the reasons why we don't tweak the generated debian/* files and opt to use these mechanisms is that the end goal of all this is to get into the upstream ROS buildfarm. We already have Autoware Core as part of the standard ROS distribution and once more and more packages from Autoware Universe get promoted to Core, the burden of maintaining the Debian packages is offloaded to the ROS buildfarm.