Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[John Meneghini]

I have a question for the upstream nvme maintainers.

Why does libnvme, as v1.3, now have a dependency on dbus?

I thought the goal was to keep the nvme management plane as streamline and daemon free as possible.  We already have a 
dependency on the udev daemon. Isn't that enough?

/John

On 2/3/23 08:47, John Meneghini wrote:
> Everyone should note that I have updated the timberland-sig repositories and re-based these pull requests onto nvme-cli v2.3 and 
> libnvme v1.3 before pushing these change upstream.
> 
> As a part of the re-base I noticed that the meson tool chain was updated in v2.3/v1.3 so I was no longer able to compile this 
> stuff on my standard RHEL 8 dev plaform.  I has to switch to Fedora 37, which seems to have the needed updated tool chain to 
> compile everything. 
 >
> Everything was there on my fedora 37 machine except for dbus.
> 
> Executing subproject libnvme:dbus
> 
> dbus| Project name: dbus
> dbus| Project version: 1.15.3
> dbus| C compiler for the host machine: cc (gcc 12.2.1 "cc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)")
> dbus| C linker for the host machine: cc ld.bfd 2.37-37
> dbus| Program python3 found: YES (/usr/bin/python3)
> dbus| Message: Detected platform : Unix (linux)
> ...
> nvme-cli 2.3
> 
>    Subprojects
>      dbus   : YES 5 warnings
>      libnvme: YES

On 2/3/23 05:08, Martin Wilck wrote:
 > On Thu, 2023-02-02 at 17:38 -0500, John Meneghini wrote:
 >> Please see the pull requests:
 >>
 >> https://github.com/linux-nvme/libnvme/pull/572
 >>
 >> https://github.com/linux-nvme/nvme-cli/pull/1791
 >>
 >> /John
 >
 > I have followed up with
 >
 > https://github.com/dracutdevs/dracut/pull/2184
 >
 > Martin