Fedora Developers Look At Packaging Up The Radeon Open Compute Stack (ROCm)

[phoronix]

Phoronix: Fedora Developers Look At Packaging Up The Radeon Open Compute Stack (ROCm)

While the ROCm "Radeon Open Compute" stack has been fully open-source for a while and in recent months even able to work fine off a mainline Linux kernel, a barrier to its adoption has been officially just have binaries produced by AMD for RHEL/CentOS/Ubuntu and not seeing these components including its OpenCL driver available through Linux distribution repositories. Fortunately, in 2019, that may finally be changing...

http://www.phoronix.com/scan.php?pag...ble-For-Fedora

[candrews]

The Radeon Open Compute projects' build systems are not in good shape which is what's causing the significant delay to inclusion in distributions including Gentoo, Debian, and Fedora. They don't install files to the appropriate locations (for example, installing libraries to /opt/rocm instead of /usr/lib), doesn't look for dependent libraries in the standard locations, and other such issues.

Here are a couple of PRs requesting fixes:
https://github.com/RadeonOpenCompute...erface/pull/25
https://github.com/RadeonOpenCompute...untime/pull/51

Until these changes are made, packaging is going to be incredibly difficult.

As an interested user and a Gentoo developer, I'm trying to get this done; you can follow along with the effort in Gentoo at https://github.com/gentoo/gentoo/pull/10724

[zxy_thf]

The Radeon Open Compute projects' build systems are not in good shape which is what's causing the significant delay to inclusion in distributions including Gentoo, Debian, and Fedora. They don't install files to the appropriate locations (for example, installing libraries to /opt/rocm instead of /usr/lib), doesn't look for dependent libraries in the standard locations, and other such issues.

Here are a couple of PRs requesting fixes:
https://github.com/RadeonOpenCompute...erface/pull/25
https://github.com/RadeonOpenCompute...untime/pull/51

Until these changes are made, packaging is going to be incredibly difficult.

As an interested user and a Gentoo developer, I'm trying to get this done; you can follow along with the effort in Gentoo at https://github.com/gentoo/gentoo/pull/10724

Sounds like ROCm was designed as a property package and still not completely migrated away from this.
(Last time I see a package installed to /opt is Intel's icc...)

[bridgman]

Sounds like ROCm was designed as a property package and still not completely migrated away from this.
(Last time I see a package installed to /opt is Intel's icc...)

I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt. Agree that we should be supporting both though, and I think there is some active discussion going on in those two pull requests.

Until very recently our top priority was getting upstream kernel drivers caught up with our internal trees... without that we weren't going to get into distros anyways... but now that is largely done I think you will see a lot more focus on making the code easy to include in distros. Thanks for helping to push this along... I'll make sure the importance of these changes is understood and prioritized.

[RahulSundaram]

I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt. Agree that we should be supporting both though, and I think there is some active discussion going on in those two pull requests

Your understanding is correct. Regardless of licensing, third party tools can default to using /usr/local or /opt. As long as the locations are easily modifiable to support distribution defaults, that's fine.

[aiomix]

Really interesting, does this give hope for davinci resolve to works on fedora with AMD GPU?

[chithanh]

(Last time I see a package installed to /opt is Intel's icc...)

I remember Oracle JDK. Or Adobe Flash plugin. But these are not fond memories.

Until very recently our top priority was getting upstream kernel drivers caught up with our internal trees... without that we weren't going to get into distros anyways... but now that is largely done I think you will see a lot more focus on making the code easy to include in distros.

If AMD had invested the work they did on the fragile "distro_install_scripts" instead into getting their CMake build into good shape, maybe that would have happened already.

[bridgman]

If AMD had invested the work they did on the fragile "distro_install_scripts" instead into getting their CMake build into good shape, maybe that would have happened already.

Sure, but the two are not interchangeable. The distro install scripts were written primarily for workstation drivers which are not a candidate for distro integration anyways.

[pal666]

I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt.

correct with emphasis on "built by". when distro builds package from your sources, they have to go to different location. so build system has to accommodate this

[zxy_thf]

I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt. Agree that we should be supporting both though, and I think there is some active discussion going on in those two pull requests.

It seems not every application follows this rule.
afaik Matlab, Wolfram Mathematica and CUDA installed themselves to /usr/local (and I'm fine with it so I could keep / minimal and leave /usr as an independent large partition).
Meanwhile Google Chrome(!), Houdini, and Adobe Reader (not sure) use /opt.