[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: ROCm Metapackages



Hi Cory - 

Not that this directly addresses your proposal below (which makes great sense to me), but I just wanted to ensure you know that the ROCm validation suite (test modules) are already packaged as a snap in the snap store:  

https://snapcraft.io/rocm-validation-suite 

This was done by one of our engineers as a proof-of-concept project a while back, but it may be useful to you or others as-is.  Being a snap, it's cross-distribution compatible to an extent too.

Kevin


On Tue, May 20, 2025 at 10:37 PM Cordell Bloor <cgmb@slerp.xyz> wrote:

Hello,

I'd like to propose a couple metapackages:

  1. rocm-dev
    The rocm-dev metapackage would depend on all -dev packages owned by the Debian ROCm Team, as well as hipcc. This package would be provided primarily so that beginner users could `apt install rocm-dev` and get started writing code or building programs that depend on ROCm without having to learn exactly what they need.

    The ROCm libraries have been available in Debian and Ubuntu for a while, yet I still get questions from people asking, "how do I install ROCm on Debian?" Many of those users talk about ROCm as if it is just monolithic thing and rather than endlessly fighting that misunderstanding, this package simply installs what they expect. More informed users can continue to install precisely what they need.

  2. rocm-tests
    This rocm-tests metapackage would depend on all the -tests packages owned by the Debian ROCm Team, plus other tools useful for hardware/software validation such as rocminfo, rocm-smi, rocm-bandwidth-test, and rocm-validation-suite utilities.

At some point, we may wish to have a rocm-doc metapackage too, but I feel it may be a bit too early to recommend that. I don't think we've entirely recovered from the upstream transition that adopted rocm-docs-core. We're not far off, though. I have faith we'll get there.

In any case, the rocm-dev package has been proposed before, but I don't think we had a conclusion to that discussion [1]. One point that was raised before was that upstream already uses the name rocm-dev. That doesn't particularly bother me given that there already exist name conflicts for existing packages such as rocm-smi and rocminfo. The workarounds already used by the upstream project would apply equally to rocm-dev.

Sincerely,
Cory Bloor

[1]: https://lists.debian.org/debian-ai/2024/10/msg00079.html



--
Canonical-20th-anniversary

Kevin Cazabon

Silicon Alliances Ecosystem Development Manager

Email: 

Kevin.Cazabon@canonical.com

Location:

United States (EST)

Mobile:

+1 585.301.7412

canonical.com

ubuntu.com


Reply to: