[DRAFT-only-for-discussion] QRMI packaging by cclaudio · Pull Request #68 · qiskit-community/qrmi

cclaudio · 2026-03-02T15:03:52Z

Fixes: #65

Add rpm and deb files for packaging
Add Makefile as a single source of truth for building, testing, checking and packaging
Add worflows for building rpm and deb
Add workflow for releasing artifacts

Some discussion topics:

I think Makefile is a good option to automate build system, at least for now. Let me know if you have a different suggestion
make rpm and make deb can be used by users and the CI. If we want to publish rpm and deb files, we should define what distros (and distro versions) has higher priority. That can save some space

Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

For usage run: make help With a Makefile we can have single source of truth on how to build, package, lint and format check QRMI. Both users and CI workflows could leverage that. Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

The caller must provide some inputs, such as the distro and distro version. Currently, this is building both the Rust and Python codes. We probably want to focus on the Rust code only for now since it has higher priority. Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

This proposes to release the source and the vendor tarballs. Users can use the latter to build QRMI in a disconnected environment. This also packages QRMI for some rpm-based and deb-based distros. We can add more distros or even postpone this if we want. Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

ohtanim · 2026-03-02T15:51:09Z

@cclaudio I haven't yet viewed all of the files though, but I have a couple of questions as starting point.

How to create a tarball which contains just 2 files - RHEL8 build of libqrmi.so and qrmi.h, as we concluded in the conversations of build and distribute libqrmi.so, and consider how to deal with the linking and #54 ?
I couldn't find the code to build libqrmi.so with RHEL 8 compiler and its development environment. Also I couldn't find packaging for RHEL8 and 9 (I can find ones for Alma, CentOS, Rocky etc..). Are they just missing ? I thought UBI8 and UBI9 containers can be used.

cclaudio · 2026-03-02T16:01:11Z

How to create a tarball which contains just 2 files - RHEL8 build of libqrmi.so and qrmi.h, as we concluded in the conversations of build and distribute libqrmi.so, and consider how to deal with the linking and #54 ?

make rpm will generate the souce tarballs and build two packages: qrmi and qrmi-devel. Currently, the qrmi-devel rpm package contains only the files

libqrmi.so
qmi.h

I couldn't find the code to build libqrmi.so with RHEL 8 compiler and its development environment. Also I couldn't find packaging for RHEL8 and 9 (I can find ones for Alma, CentOS, Rocky etc..). Are they just missing ? I thought UBI8 and UBI9 containers can be used.

Currently, the PR does not include any RHEL. I can check if the ubi8 and ubi9 provides all the packages we need to build the libqrmi

ohtanim · 2026-03-02T15:59:19Z

packaging/debian/control

+Description: Quantum Resource Management Interface (QRMI)
+ QRMI is a set of libraries that provide a unified interface to control
+ the state of quantum resources. It exposes a C API (libqrmi.so / qrmi.h)
+ and a Python API built on top of the same Rust core.


Question: What do you mean by "same Rust core"?

The libqrmi.so built with cargo build --release and the one built with maturin build --release are different. The latter includes src/pyext.rs, references Python’s shared library symbols, and attempts to link to them at runtime.

I used AI to assist me with some specific tasks. Description was AI generated

ohtanim · 2026-03-02T16:00:26Z

packaging/debian/control

+               g++,
+               make,
+               cmake,
+               libssl-dev,


libssl-dev is no longer required. This dependency was removed by #67 . Also next zlib1g-dev is no longer needed.

ohtanim · 2026-03-02T16:01:41Z

packaging/debian/control

+Section: libdevel
+Depends: libqrmi (= ${binary:Version}), ${misc:Depends}
+Description: Development files for libqrmi
+ Header file (qrmi.h) and static library (libqrmi.a) for building


Why does this package contain only static library and header ?
I think libqrmi.so should be also included in this package for development.

That description is outdated. The package is not including the static library (IIUC, the static library is linked to glibc and if so the QRMI code would be contaminated with GPL)

ohtanim · 2026-03-02T16:04:02Z

.github/workflows/release.yml

+  push:
+    tags:
+      - "v*.*.*"
+jobs:


package-rhel8, package-rhel9 and package-rhel10 are missing. At least, we need to provide packages for rhel8 and 9 because most of HPC data center uses.

How do we build libqrmi.so with RHEL8 compiler/linker ?

How do we build libqrmi.so with RHEL8 compiler/linker ?

That depends:

for the CI we just need to add one more job in the release.yaml for each RHEL version we want

for users via cmdline, they would need to run make build inside a container. We could create a Dockerfile (docker native) or Containerfile (podman native)

package-rhel8, package-rhel9 and package-rhel10 are missing. At least, we need to provide packages for rhel8 and 9 because most of HPC data center uses.

OK, I will add RHEL 8 9 and 10

ohtanim · 2026-03-02T16:04:22Z

.github/workflows/release.yml

+      distro: almalinux
+      distro-version: "9"
+      container-image: almalinux:9
+


almalinux10 is not supported ?

@awennersteen I can add almalinux10

ohtanim · 2026-03-02T16:04:37Z

.github/workflows/release.yml

+      distro: rockylinux
+      distro-version: "9"
+      container-image: rockylinux:9
+


rockylinux 10 is not supported ?

I can add rockylinux 10

ohtanim · 2026-03-02T16:09:26Z

packaging/rpm/qrmi.spec

+#
+# Packages produced:
+#   qrmi          - shared library (libqrmi.so) and C header (qrmi.h)
+#   qrmi-devel    - development files (static library + header)


I'm confused with above. Why do we need to create 2 separate packages ? - Both will be used by developers for development because each contains header file. I thought it is enough to create 1 package that contains libqrmi.so, libqrmi.a and qrmi.h.

ohtanim · 2026-03-02T16:10:04Z

packaging/rpm/qrmi.spec

+# Build requirements:
+#   - Rust toolchain >= 1.91  (install via rustup; not available as an RPM on EL8/EL9)
+#   - cargo-vendor (bundled with cargo)
+#   - gcc, make, cmake, openssl-devel, zlib-devel, pkg-config


please remove openssl-devel and zlib-devel. They are no longer required by recent change #67.

ohtanim · 2026-03-02T16:10:28Z

packaging/rpm/qrmi.spec

+BuildRequires:  gcc-c++
+BuildRequires:  make
+BuildRequires:  cmake
+BuildRequires:  openssl-devel


openssl-devel is no longer needed.

ohtanim · 2026-03-02T16:10:42Z

packaging/rpm/qrmi.spec

+BuildRequires:  make
+BuildRequires:  cmake
+BuildRequires:  openssl-devel
+BuildRequires:  zlib-devel


zlib-devel is no longer needed.

awennersteen · 2026-03-02T16:21:54Z

Personally, I think we can treat RHEL interchangeability with rocky and alma.
Rocky and Alma are binary compatible with official RHEL.
So e..g Rocky 8 builds work on Alma 8 and RHEL 8.

make rpm will generate the souce tarballs and build two packages: qrmi and qrmi-devel. Currently, the qrmi-devel rpm package contains only the files
libqrmi.so
qmi.h

I would like it if this is available as a tarball though, personally.
I've tested locally and a Rocky built libqrmi.so worked on ubuntu, for exmaple

I fear we're complicating things here

ohtanim · 2026-03-02T16:30:59Z

How to create a tarball which contains just 2 files - RHEL8 build of libqrmi.so and qrmi.h, as we concluded in the conversations of build and distribute libqrmi.so, and consider how to deal with the linking and #54 ?

make rpm will generate the souce tarballs and build two packages: qrmi and qrmi-devel. Currently, the qrmi-devel rpm package contains only the files

libqrmi.so

qmi.h

@cclaudio Are you considering providing RPM/Deb packages instead of the tarball distribution that you and Alex discussed and agreed on earlier? There are pitfalls to this approach.
Suppose multiple developers share the same system — for example, the login nodes or pre/post nodes on an HPC cluster. If Developer-A needs a specific version of libqrmi.so/qrmi.h, while Developer-B needs a different version for his/her development, I think RPM/Deb‑based distribution will not allow installing those multiple versions simultaneously.
In addition, wouldn’t installation require admin privileges in general? - How HPC user manage?

Considering those backgrounds, I proposed to create a tarball, instead of RPM/deb.

awennersteen · 2026-03-02T16:32:55Z

packaging/rpm/qrmi.spec

+%{_libdir}/libqrmi.so
+%{_includedir}/qrmi.h
+
+# ---------------------------------------------------------------------------


on file in general: OK after looking and thinking more I understand more about why you want to have the rpm specs. in principle ok

awennersteen · 2026-03-02T16:33:41Z

Makefile

+# Format check libqrmi, dependencies, examples and binaries
+fmt: check-rustfmt
+	cargo fmt --all -- --check --verbose
+
+lint: check-clippy
+	cargo clippy --all-targets -- -D warnings


should also lint and format python code

awennersteen · 2026-03-02T16:34:23Z

Makefile

+lint-bins: check-clippy
+	cargo clippy --bin task_runner --features="build-binary" -- -D warnings
+	cargo clippy --bin stubgen --features="pyo3" -- -D warnings
+
+lint-rust: lint lint-bins


I don't understand this, why do we want to lint bins? what does that mean

awennersteen · 2026-03-02T16:35:25Z

Makefile

+	maturin build --release
+
+fmt-wheels: check-venv
+	.venv/bin/black --check ./python


should not be hardcoded the way you setup your python venv imo

ohtanim · 2026-03-02T16:42:09Z

.github/workflows/package-rpm.yml

@@ -0,0 +1,125 @@
+---
+# SPDX-License-Identifier: Apache-2.0


Suppose multiple developers share the same system — for example, the login nodes or pre/post nodes on an HPC cluster. If Developer-A needs a specific version of libqrmi.so/qrmi.h for his/her development, while Developer-B needs a different version, I think RPM/Deb‑based distribution will not allow installing multiple versions simultaneously.
In addition, wouldn’t installation require admin privileges?

Could you please consider to support a simple tarball distribution, which contains libqrmi.so, libqrmi.a and qrmi.h ?

awennersteen · 2026-03-02T17:22:14Z

I've reviewed and thought some more. (Cross-postedo on Slack)

I think I would advise to drop the current MR, and just put out the part building on RHEL 8 - based code, and uploading that artifact.

Then we can discuss more deeply what we need in terms of the RPM builds and Makefiles and everything.
I think my stance right now is to keep it simple, but I do see the benefits of having the RPM package and the vendor distribution to allow for installs without any internet connection, and I do agree with the Makefile

]Simply because I don't see us finalizing the current PR at a level we're all happy with and agree with, and on my side I have some urgency on the libqrmi.so+qrmi.h availability.

cclaudio · 2026-03-02T17:46:59Z

I think this PR fullfiled its initial purpose which is discussing direction. Thank you all for your quick feedback!

I am keeping this PR opened so that we don't loose the discussion and we can come back to it later.

For the sake of time, I am creating another PR where we can laser focus on:

Makefile: build libqrmi.so+qrmi.h
CI: build only one rpm package, and it is based on registry.access.redhat.com/ubi8. The rpm will have only the libqrmi.so and qrmi.h artifacts
distribute the rpm and the two tarballs (source and vendors)

ohtanim · 2026-03-02T22:51:31Z

Are we going to deliver our libqrmi.so/qrmi.h in form of RPM/deb, not a simple tarball ? Then, I have some concerns about distributing our library and header files using RPM/deb packages, especially in the context of HPC environments.

Concerns about distributing our library via RPM/deb packages

Lack of support for installing multiple versions side by side
RPM/deb packages are generally designed to install a single version system-wide.
This becomes problematic when we need to compare multiple versions of the library.
For example, if we observe a performance regression or a functional degradation, a common workflow is to install several versions and run the same benchmark or test suite against each version to compare results. With RPM/deb, this typically requires repeatedly uninstalling and reinstalling different versions, which introduces friction and makes such comparisons unnecessarily cumbersome.
In contrast, installing multiple versions side by side (e.g., under versioned prefixes) allows users to switch versions easily and reproducibly.
Inability for multiple users to use different versions on the same system
HPC systems are inherently multi-user environments. During development, it is common for different users to work with different versions of the same library (e.g., stable, development, or nightly builds).
RPM/deb packages install software system-wide and therefore do not allow each user to independently select or install their own version. This makes them poorly suited for active development workflows where flexibility at the user level is required.
System-wide installation is undesirable in HPC environments
RPM/deb packages assume system-wide installation, typically requiring administrative privileges.
In HPC data centers, software is often built on shared systems such as login nodes, and system administrators are generally reluctant to install frequently changing development libraries globally. Introducing or updating RPM/deb packages for such libraries increases operational risk and administrative overhead.
Integration with existing HPC software delivery mechanisms
In HPC environments, software is typically exposed to users via Spack and/or Environment Modules.
When distributing software as a tarball with a clear directory structure, it is straightforward to register it with these systems. In contrast, integrating RPM/deb packages into existing module or Spack-based workflows is more cumbersome and does not align well with established operational practices.

Please ignore if you've already addressed above my concerns.

cclaudio · 2026-03-03T00:31:37Z

Thank you @ohtanim. We have not addressed all the points you mentioned.

# ldd /usr/lib64/libqrmi.so.0.11.0 
	linux-vdso.so.1 (0x00007f3d840e0000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3d82af3000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3d828d3000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f3d82551000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f3d8234d000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f3d81f77000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3d83e00000)

Currently, these are the libraries that the libqrmi.so is depending on. Since all of them are already installed in the UBI8, I think it should be fine to publish a tarball like libqrmi-0.11.0-el8-x86_64.tar.gz with libqrmi.so and the qrmi.h.

I will incorporate that in the new PR

OkuyanBoga · 2026-03-23T09:03:41Z

I agree tarballs are important for people who want more flexibility, but, at the same time, I think RPM/deb packages are still very useful. I believe, in many practical cases for hpc-admins, one installation is enough, and package-manager install is just the simplest option. So I’d see packages as a useful extra, not something that replaces tarballs.

awennersteen · 2026-03-23T09:36:06Z

in many practical cases for hpc-admins, one installation is enough, and package-manager install is just the simplest option.

Our feedback from Julich on slack was that they prefer to install from source build. with Spack / easybuild or similar I think.

cclaudio added 6 commits March 2, 2026 09:51

Add packaging files for rpm and deb

e5cc4d3

Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

Add Makefile

d428f3b

For usage run: make help With a Makefile we can have single source of truth on how to build, package, lint and format check QRMI. Both users and CI workflows could leverage that. Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

CI: Add reusable workflow for deb packaging

240442c

Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

[WIP] Started updating workflows to use the Makefile

c33c5df

Signed-off-by: Claudio Carvalho <cclaudio@ibm.com>

cclaudio requested review from OkuyanBoga, awennersteen and ohtanim as code owners March 2, 2026 15:03

cclaudio marked this pull request as draft March 2, 2026 15:05

ohtanim requested changes Mar 2, 2026

View reviewed changes

awennersteen reviewed Mar 2, 2026

View reviewed changes

ohtanim requested changes Mar 2, 2026

View reviewed changes

Conversation

cclaudio commented Mar 2, 2026

Uh oh!

ohtanim commented Mar 2, 2026

Uh oh!

cclaudio commented Mar 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cclaudio Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

awennersteen commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ohtanim commented Mar 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

awennersteen commented Mar 2, 2026

Uh oh!

cclaudio commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ohtanim commented Mar 2, 2026

Concerns about distributing our library via RPM/deb packages

Uh oh!

cclaudio commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

OkuyanBoga commented Mar 23, 2026

Uh oh!

awennersteen commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

cclaudio Mar 2, 2026 •

edited

Loading

awennersteen commented Mar 2, 2026 •

edited

Loading

cclaudio commented Mar 2, 2026 •

edited

Loading

cclaudio commented Mar 3, 2026 •

edited

Loading

awennersteen commented Mar 23, 2026 •

edited

Loading