Hi Christian,
Yes, but a bit more complicated than the above because -tests package names match the SONAME of the library they were built against (which is good).
That is partly why I proposed the rocm-tests package. I keep having to tell people how to test if ROCm works on their platform (arm64, ppc64el, new GPU, etc) and it always starts off with `sudo apt install librocblas0-tests libhipblas0-tests librocrand1-tests libhiprand1-tests librocthrust-tests ...` and even I have trouble remembering the SONAMES for them all.
Is handling the SONAMEs for rocm-tests any more complicated than specifying each of those explicitly in the rocm-tests depends list? I presume we'd have to update that list manually anyway.
This meta-package should also provide a utility to run all of the tests. This would be quite simple if -tests packages switched to the unified interface that I proposed here [1], which wouldn't be much work.
I like your proposal, though would it run
afoul of the new Debian Policy [2]?
> Two different packages must not install programs with different functionality but with the same filenames. This also applies when they are installed into different directories on the default (user or root) PATH.
I suppose it depends on whether running different tests is
"different functionality."
At some point, we may wish to have a rocm-doc metapackage tooAnother meta-package to consider would be simply rocmX.Y with all the libraries, no hipcc and whatever. For when a user has a ROCm-needing binary from somewhere outside Debian, and no need for -dev stuff.
I'm not sure I understand how this would work. We'd only have one
version of ROCm available on Debian at once, right? If users would
only be able to install one specific rocmX.Y at any given time,
would that really be useful? I think I must be misunderstanding
how this would work.
Sincerely,
Cory Bloor
[2]:
https://www.debian.org/doc/debian-policy/ch-files.html#binaries