Re: Proposal to start bundling LLVM in the rocm-llvm package
Hi Tim,
On 2025-06-26 17:26, Tim Flink wrote:
> I'm proposing that the rocm-llvm package be changed from building on top
> of system llvm to bundling the full amdclang (the ROCm llvm-project fork
> [1] ). This email is meant to start a discussion around whether this
> change would work well for Debian.
Thanks for getting this going. I guess that at some point, the question
had to be addressed.
If I'm skipping over a few things below, it's because I don't have any
meaningful to contribute right now.
> The current rocm-llvm package [2] builds on top of the system LLVM
> packages with just the bits where amdclang differs from upstream LLVM.
> This is similar to the way that Fedora used to package amdclang but that
> package was changed to bundle the required bits of LLVM for several
> reasons:
>
> 1. There was a mismatch in pace between system LLVM updates and amdclang
> updates leading to multiple cases of ROCm and amdclang being broken when
> a version of Fedora was released.
Our releases tend to have multiple versions of system LLVM. Would this
alleviate the problem to a degree?
And to ask the naive question: if the mismatch between LLVM and amdclang
paces were resolved upstream, could this eliminate the problem entirely,
for all downstream distributions?
> 3. amdclang is mostly tested with the bundled LLVM and may contain ROCm
> specific bugfixes which have not yet been accepted upstream.
Are these fixes large and/or numerous? Are these always accepted upstream?
> Debian hasn't had the same problems with LLVM update pace that we had in
> Fedora but the other points remain relevant. While there is work that
> has to be done either way, there are benefits that come from bundling
> the amdclang LLVM instead of relying on system LLVM.
I agree about the benefits. Just providing backports alone would be much
simpler if we didn't need to touch a system-wide component to get the
latest features.
I do also have concerns though. For example, bundling might make
shipping easier, but technically we then also need to actively maintain
this fork (you address this below), which in the end might be more
complicated than the unbundled approach.
In the end, we will need to make the case to the Release Team, the
Security Team, and ftp-master (I think).
> It's no secret that my team is working on ROCm packages for Ubuntu and
> for the sake of transparency, that effort is not unrelated to this
> proposal - we anticipate packaging a bundled amdclang for Ubuntu.
> However, that doesn't mean that we see this proposal as the only way
> forward. My team's intent is to work with the Debian community to do
> both the Debian packages and the future Ubuntu packages.
>
> One last thing - to make sure that I'm being clear, this proposal isn't
> just a one-and-done change that's thrown over the wall. My team and I
> would be participating in the longer-term maintenance beyond this
> initial change.
Do you have a (rough) idea how much work this would entail?
For example, I think there would be a strong case for a bundled approach
if amdclang were to closely track upstream's bugfix and security releases.
On the other hand, if amdclang just "snapshots" LLVM to begin a new
development cycle, this would probably weaken the case.
I'd also like to at least point out that not bundling might also be
productive by raising the pressure for amdclang to improve the LLVM
upstreaming process. I think the kernel is a good example for when this
works well, and when it doesn't (needing a third-party kernel or
out-of-tree module is rarely a good sign).
Best,
Christian
Reply to: