Subject: Bug#1022797: librocm-smi-dev: find_package(rocm_smi) fails due to missing liboam

From: Cordell Bloor <[email-masked]>
Date: Wed, 26 Oct 2022 01:19:34 -0600

Package: librocm-smi-dev
Version: 5.2.3-1
Severity: normal

Dear Maintainer,

I was working on packaging rccl when I encountered an error stemming
from find_package(rocm_smi). The text of the error was:

    CMake Error at /lib/cmake/rocm_smi/rocm_smiTargets.cmake:102 (message):
      The imported target "oam" references the file
    
         "/usr/lib/liboam.so.1.0"
    
      but this file does not exist.  Possible reasons include:
    
      * The file was deleted, renamed, or moved to another location.
    
      * An install or uninstall procedure did not complete successfully.
    
      * The installation package was faulty and contained
    
         "/lib/cmake/rocm_smi/rocm_smiTargets.cmake"
    
      but not all the files it references.
    
    Call Stack (most recent call first):
      /lib/cmake/rocm_smi/rocm_smi-config.cmake:53 (include)
      CMakeLists.txt:282 (find_package)

    -- Configuring incomplete, errors occurred!

If you look through rocm_smiTargets.cmake, you can see that the
librocm-smi-dev package is creating CMake targets that refer to liboam.

As a workaround, I added liboam-dev directly to the rccl build-depends
and installed the package manually. This resolved the problem. However,
it seems to me that either rocm_smi should not be exporting the oam
target or librocm-smi-dev should depend on liboam-dev. I'm not sure
which option would be better.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages librocm-smi-dev depends on:
ii  librocm-smi64-1  5.2.3-1

librocm-smi-dev recommends no packages.

librocm-smi-dev suggests no packages.

-- no debconf information

---

From: Étienne Mollier <[email-masked]>
Date: Wed, 26 Oct 2022 20:44:34 +0200

Hi Cory,

> which option would be better.

I'm not too sure yet of the implementation to not export the oam
target; this looks to have been autogenerated by cmake.  About
the dependency, I'm thinking twice before making that a hard
one, since it is possible to make use of the headers without
pulling the oam, at least from my quick test.

What do you think about simply recommending the installation?

It would be installed by regular users, and the ones who know
what they are doing can always remove, or install with option
--no-recommends, if that suite their needs.

Have a nice day,  :)
-- 
Étienne Mollier <[email-masked]>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.
On air: Art Of Illusion - Devious Savior

---

From: Cordell Bloor <[email-masked]>
Date: Wed, 26 Oct 2022 13:36:26 -0600

Hi Étienne,

> What do you think about simply recommending the installation?

I think recommending the package makes sense, as upstream seems to 
install them together. That's a good start, but I think we can do more 
than that.

The oam target code is generated by CMake, but it appears to be exported 
by this line here: 
https://github.com/RadeonOpenCompute/rocm_smi_lib/blob/rocm-5.3.0/CMakeLists.txt#L183

(Incidentally, "rcom_smi_target.cmake" looks like a typo.)

I think we could probably create a patch that splits the rocm_smi and 
oam CMake config files. We'd remove oam from the rocm_smi exported 
targets and create an oam-config.cmake file, so it could be exported as 
its own thing. find_package(oam) would then be used to get the oam target.

To make Debian's behaviour compatible with upstream when both libraries 
are installed, we could modify the rocm_smi-config.cmake template 
(rocm_smi-config.cmake.in), so that find_package(rocm_smi) does a 
find_package(oam QUIET).

And maybe try to upstream the split?

Sincerely,
Cory Bloor

---

From: Étienne Mollier <[email-masked]>
Date: Sat, 10 Dec 2022 16:45:20 +0100

Hi Cory,

Cordell Bloor, on 2022-10-26:
> The oam target code is generated by CMake, but it appears to be exported by
> this line here: https://github.com/RadeonOpenCompute/rocm_smi_lib/blob/rocm-5.3.0/CMakeLists.txt#L183
> 
> I think we could probably create a patch that splits the rocm_smi and oam
> CMake config files. We'd remove oam from the rocm_smi exported targets and
> create an oam-config.cmake file, so it could be exported as its own thing.
> find_package(oam) would then be used to get the oam target.
> 
> To make Debian's behaviour compatible with upstream when both libraries are
> installed, we could modify the rocm_smi-config.cmake template

Some time ago, I tried to implement such a split, but to be
honest, my competency with cmake is not what it should be to
address the issue that way.  But knowing this is doable, I'm
neither enthusiastic about my "Recommends:" solution anymore.
I'm afraid I might stall that particular issue.

But thanks for the idea and the clues,
-- 
Étienne Mollier <[email-masked]>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.

---

From: Cordell Bloor <[email-masked]>
Date: Thu, 1 Feb 2024 11:06:20 -0700

Hi Etienne,

Could we add 'Recommends: liboam-dev' to librocm-smi-dev until the CMake 
config in the latter is modified to make liboam-dev optional? There has 
been no progress on this issue for some time, so I think it may be worth 
applying that mitigation.

I wouldn't consider the addition of the Recommends to be a fix for this 
issue, so I'm fine with leaving the bug open even after the mitigation 
is applied.

Sincerely,
Cory Bloor

---

From: Étienne Mollier <[email-masked]>
Date: Sun, 4 Feb 2024 16:39:21 +0100

Hi Cory,

Cordell Bloor, on 2024-02-01:
> config in the latter is modified to make liboam-dev optional? There has been
> no progress on this issue for some time, so I think it may be worth applying
> that mitigation.

I reread through the bug entry, and I agree.  If there are no
blockers or objections, I'm also considering taking that
opportunity to migrate the version 5.7 to unstable.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <[email-masked]>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-    on air: Glass Hammer - If The Stars

---

From: Étienne Mollier <[email-masked]>
Date: Sun, 4 Feb 2024 18:08:30 +0100

Control: severity -1 wishlist

The package is uploaded.  I reduce the severity to a wishlist
item, as we will have a workaround in place.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <[email-masked]>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-    on air: Different Strings - The Abyss