I'd say it's quite reasonable to include nbd client in solus.

Another use-case is to mount a VM disk image. One uses qemu-nbd to serve the disk image, then uses nbd-client to mount it.

I'm using both ceph-rbd and nbd, through the kernel interface.

The reason I explicitly only requested rbd kernel module, not the ceph userland utility, is that ceph is a huge package.
On the other hand, nbd is a small utility, with roughly 2 releases every year.

I'd be able to commit a patch once it's accepted.

I have a patch to submit, but wondering if it should include the server binary.
If the server executable is included, i feel obliged to add the default config file and systemd service unit file. However I don't think I feel comfortable to enable nbd service.

Thanks hashhsah.

Can anyone chime in on how to best handle that? I'd hate to see the request go stagnant while someone is actively interested in packaging it

From my perspective, this is something I would want to explicitly configure before any services are enabled... so to me it makes the most sense to include the default config/systemd service, but keep it disabled and let the user enable it.