Packaging CUDA and ROCm Toolkits on Debian

This article examines the packaging strategies employed to distribute the NVIDIA CUDA and AMD ROCm GPU compute platforms on the Debian operating system. It explores how Debian's strict adherence to software freedom affects archive placement, contrasts AMD's open-source source-build methodology with NVIDIA's proprietary binary-repackaging pipeline, and details the dependency management and modularization practices used by Debian package maintainers to manage these complex toolkits.

Licensing and Debian Archive Placement

Debian strictly categorizes software into components based on the Debian Free Software Guidelines (DFSG):

• AMD ROCm (Debian main): ROCm is designed around open-source components, including driver interfaces, compilers, and mathematical libraries. Because the upstream code is primarily licensed under permissive licenses (such as MIT and Apache 2.0), the Debian ROCm Team packages the stack directly into main.
• NVIDIA CUDA (Debian contrib and non-free): CUDA relies on closed-source, proprietary components, including the nvcc compiler backend, proprietary runtime libraries (such as cuBLAS and cuDNN), and the proprietary NVIDIA display driver. As a result, the toolchain itself is packaged in non-free. Free software packages that build against CUDA but require it to function are placed in contrib.

ROCm Packaging Strategy: Source Builds and Modularization

Debian packages ROCm by building the entire stack directly from source code, rather than redistributing upstream binary tarballs. This approach requires strict dependency management and integration with existing system components:

• LLVM/Clang Integration: ROCm relies on AMD's customized LLVM forks (AMD Device Libs, ROCm Device Libs). The Debian packaging effort works toward decoupling ROCm from pinned forks, compiling against system versions of LLVM/Clang where possible, or maintaining target-specific intermediate libraries.
• Component Modularization: Upstream ROCm releases are decomposed into distinct, fine-grained source packages:
  • Low-level drivers and runtimes: rocm-core, libhsa-runtime64, and rocminfo.
  • Toolchain components: hip-runtime-amd, hipcc, and associated header files.
  • Accelerated math and ML libraries: rocblas, rocfft, rocrand, and miopen-hip.
• Hardware Architecture Splitting: Because pre-compiling GPU code for every GCN/RDNA generation (e.g., gfx900, gfx1030, gfx1100) leads to immense package sizes and long build times, maintainers selectively target common architectures and use Debian build profiles to manage storage footprints.

CUDA Packaging Strategy: Binary Redistribution and Stubs

Because NVIDIA does not release the full source code for the CUDA compiler or libraries, the Debian NVIDIA Maintainers team uses a redistribution and wrapping strategy:

• Repackaging Upstream Runfiles: The core nvidia-cuda-toolkit package unpacks and inspects upstream installer archives, distributing headers, documentation, tools, and binaries into DFSG-compliant filesystem locations (e.g., standard directories under /usr/lib/x86_64-linux-gnu instead of monolithic directories like /usr/local/cuda).
• Driver Decoupling via Stubs: Debian separates the user-space development toolkit from the kernel-level driver. It packages CUDA stub libraries (libcuda.so.1 stubs), allowing developers to compile CUDA-accelerated software on build nodes that lack physical NVIDIA hardware or loaded kernel modules.
• Granular Dependency Tiers: Debian organizes CUDA packages into logical units:
  • Runtime dependencies: Essential shared objects packaged to fulfill runtime requirements without pulling in heavy developer tooling.
  • Development packages: Headers and compiler wrappers (nvidia-cuda-toolkit) designated exclusively for build environments.
  • Co-installability management: Using Debian's update-alternatives mechanism to switch between GCC versions that match CUDA’s supported compiler constraints.

Technical Maintenance Differences