Hi Christian, On 2024-03-01 12:38, Christian Kastner wrote:
I'd lean the other way, towards rocm-llvm and rocm-clr source packages.
Staying close to upstream's way is usually easier to maintain, as any
delta adds maintenance work, and deltas tend to increase over time.
Staying close to upstream can also avoid some user confusion ("what is
Debian's rocm-hipamd and how does it relate to rocm-clr?"). Related: I
think we should also check what other distros, especially Fedora, are doing.
Consolidation also frequently makes things easier. With one source
package, the build process becomes slightly more complicated, but in
future it's just one package to update, rather than N.
The downside of new source packages is a bit of extra maintenance work
when transitioning (source: needs to go through NEW, binaries: need to
be taken over, eg: rocm-llvm taking over the hipcc package), but that's
manageable to a degree.
I'm not leaning too strongly though, happy to follow the other path if
it turns out to be the more popular one.
Fedora is matching the upstream structure. If that is the preference on Debian as well, that works for me. We can transition the source packages to rocm-llvm when we integrate ROCm 6.1.
The tricky question is how to handle the transition to rocm-clr. The last ROCm release using the old rocm-hipamd repo was ROCm 5.6.1. If we're go to send it through NEW for the switchover to rocm-clr, I suppose we might as well skip ROCm 5.7.1 and go straight to ROCm 6 since that version needs to go through NEW anyway. An alternative approach would be to take the rocm-clr sources into rocm-hipamd so we can update to HIP from ROCm 5.7.1, and then transition the source package from rocm-hipamd to rocm-clr with the update to ROCm 6.0 when it's going through NEW anyway.
I must admit, part of my apprehension on renaming the rocm-hipamd source package immediately is that this would mean that Ubuntu 24.04 would get HIP 5.6.1 rather than 5.7.1. The changelog for 5.7.1 is pretty short and nothing stands out as vital [1], but the commit log suggests more substantial changes [2]. If possible, I would prefer to help them to freeze for their LTS release on the final release in the ROCm 5 series. However, if that would require an approach that is contrary to best-practice in Debian, then upstream made their bed and will have to lie in it.
Sincerely, Cory Bloor[1]: https://github.com/ROCm/clr/blob/rocm-5.7.1/CHANGELOG.md#hip-571-for-rocm-571
[2]: https://github.com/ROCm/clr/compare/rocm-5.6.1...rocm-5.7.1