Re: Upstream reorganization of rocm-device-libs, rocm-compilersupport and rocm-hipamd
Hi Cory,
On 2024-03-01 08:43, Cordell Bloor wrote:
> Hi folks,
>
> The upstream ROCm project has reorganized a few libraries.
>
> The rocm-compilersupport and rocm-device-libs source packages have been
> consolidated into a sub-directory of rocm-llvm [3]. The sources for the
> hipcc binary package (currently part of the rocm-hipamd source package)
> have also been moved into rocm-llvm.
>
> The rocclr, opencl and hipamd tarballs that were part of the rocm-hipamd
> multi-upstream tarball [4] have been consolidated into a single upstream
> tarball known as rocm-clr [5]. This is practically identical to the
> existing rocm-hipamd source package in Debian.
>
> My questions:
>
> 1. We're clearly going to have to do some filtering on the upstream
> tarball for rocm-compilersupport and rocm-device-libs. Do we want to
> retain the separate rocm-compilersupport and rocm-device-libs source
> packages, or introduce a new rocm-llvm source package? We'll have to
> repack the upstream tarball either way, because otherwise it will
> contain a full copy of LLVM. I also don't think anything changed about
> the structure of the compilersupport or device libraries. Their build
> systems remain independent. The libraries are now just in
> sub-directories of the same upstream tarball.
>
> 2. Do we want to just update the upstream source for rocm-hipamd to be
> the rocm-clr repo? It has essentially the same content and almost the
> same structure as our existing rocm-hipamd MUT. However, the hipamd
> component is moved to a subdirectory (rather than being the root as in
> the Debian MUT). Renaming the source package might be more clear than
> just changing the upstream URL, but it might also just be unnecessary work.
>
> I lean towards just keeping the Debian source packages unchanged (in
> both cases), but I'm not sure if that is appropriate. Thoughts?
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.
Best,
Christian
> [1]: https://tracker.debian.org/pkg/rocm-compilersupport
> [2]: https://tracker.debian.org/pkg/rocm-device-libs
> [3]:
> https://github.com/ROCm/llvm-project/tree/e2da7b28a0f1cadb4beb7b014b90bc6b7ab58f1e/amd
> [4]: https://tracker.debian.org/pkg/rocm-hipamd
> [5]: https://github.com/ROCm/clr
>
Reply to: