[PACKAGING] Investigate and implement official OBS (openSUSE Build Service) packaging for HDF5

### Summary

There is no official, HDF Group-maintained native Linux packaging, meaning users across many distributions rely on volunteer-maintained community specs that often lag behind upstream releases or deviate from HDF Group-recommended build configurations. This issue tracks investigation and implementation of an official [[Open Build Service (OBS)](https://build.opensuse.org/)](https://build.opensuse.org) project for HDF5, which can produce native packages (RPM and DEB) for a broad range of Linux distributions simultaneously from a single source definition.

---

### Motivation

- OBS can build for all major Linux distributions from a single `.spec`/`debian/` source — making it the most leveraged path to broad official native packaging coverage.
- An official HDF Group OBS project would provide GPG-signed, promptly-updated packages installable via each distro's native package manager (`zypper`, `dnf`, `apt`).
- Reduces fragmentation: rather than maintaining separate packaging efforts per distro, one OBS project serves all of them.
- Aligns with NSF Safe-OSE project goals around software availability, distribution, and supply chain integrity.

---

### Target distributions (initial)

OBS supports building for all of these from a single project:

| Family | Targets |
|---|---|
| openSUSE / SUSE | Tumbleweed, Leap 15.x, SLE 15-SPx |
| Fedora / RHEL | Fedora 40/41, RHEL 9, CentOS Stream 9 |
| Debian / Ubuntu | Debian 12, Ubuntu 22.04, 24.04 |

The set of active targets should be determined during investigation based on HDF5 user base data and maintenance burden.

---

### Scope of investigation

**Phase 1 — Audit existing packaging**

- [ ] Inventory all existing OBS projects and distro-maintained packages containing HDF5 (OBS `science:HPC`, `devel:libraries:c_c++`, Fedora `rpms/hdf5`, Debian `science` team, Ubuntu `universe`, etc.)
- [ ] Evaluate currency, completeness, and CMake flag fidelity of existing specs/rules
- [ ] Document subpackage landscape across distros: serial, parallel (OpenMPI, MPICH), Java, Fortran, tools, filter plugins
- [ ] Identify gaps and inconsistencies relative to HDF Group recommended build configuration

**Phase 2 — Spec and rules file development**

- [ ] Author a canonical `hdf5.spec` (RPM) and `debian/` rules (DEB) covering:
- Serial and parallel (OpenMPI, MPICH) build variants
- Fortran and C++ interfaces
- Java bindings (conditional)
- High-level APIs (HL library)
- Filter plugins
- `ctest`-based `%check` / `dh_auto_test` with appropriate chroot exclusions
- `_service` file pointing to canonical HDF Group release tarball
- [ ] Validate builds locally with `osc build` across RPM and DEB targets
- [ ] Document and curate ctest exclusion list for chroot environments (MPI spawning, `/proc` access, fd limits)

**Phase 3 — OBS project setup**

- [ ] Create official OBS project under an HDF Group namespace
- [ ] Configure all target distributions and architectures (x86\_64, aarch64 at minimum)
- [ ] Establish GPG signing key and key distribution mechanism
- [ ] Document release workflow: GitHub tag → OBS `_service` update → build → publish

**Phase 4 — CI integration (stretch)**

- [ ] Investigate triggering OBS builds automatically from GitHub Actions on new release tags via the OBS REST API
- [ ] Add OBS packaging update to the official post-release checklist

---

### Key technical considerations

- **MPI combinatorics**: Parallel builds require separate packages per MPI flavor. OBS `%bcond_with` + multibuild handles this for RPM; Debian requires separate source packages or build profiles. Tradeoffs should be documented.
- **RPM vs DEB spec maintenance**: These are distinct file sets with different conventions. Consider whether a single maintainer or split ownership makes more sense long-term.
- **`%check` in chroot**: HDF5's test suite makes assumptions (MPI spawning, writable `/tmp`, fd counts) that OBS chroots restrict. A maintained ctest exclude list is required.
- **Filter plugins**: Decide whether third-party filters (blosc, lzf, bshuf) are co-packaged or left to separate packages consuming the HDF5 plugin ABI.
- **Version cadence**: Decide whether OBS tracks stable releases only, or also publishes RC builds in a separate `-testing` project.
- **Relationship to distro-maintained packages**: Clarify The HDF Group's position — is the goal to *replace* or *supplement* distro packages? Coordination with Fedora, Debian science team, etc. is advisable to avoid duplication.

---

### Success criteria

- [ ] `zypper`/`dnf`/`apt` install of `hdf5-devel` from the HDF Group OBS repo works correctly on a clean system for at least three distribution families
- [ ] Parallel (OpenMPI) variant installs and links correctly alongside the serial variant
- [ ] New HDF5 releases are reflected in OBS within one week of the GitHub release tag
- [ ] Spec and packaging files are committed to a canonical location (this repo or a dedicated `hdf5-packaging` repo) and open for community contribution
- [ ] Packages are GPG-signed and the signing key is published on the HDF Group website

---

### References

- [[Open Build Service](https://build.opensuse.org/)](https://build.opensuse.org)
- [OBS `osc` CLI documentation](https://en.opensuse.org/openSUSE:OSC)
- [[OBS Debian/Ubuntu packaging guide](https://en.opensuse.org/openSUSE:Build_Service_Debian_builds)](https://en.opensuse.org/openSUSE:Build_Service_Debian_builds)
- Existing community RPM spec: `https://build.opensuse.org/package/show/science:HPC/hdf5`
- Fedora package: `https://src.fedoraproject.org/rpms/hdf5`
- conda-forge feedstock (for build flag reference): `https://github.com/conda-forge/hdf5-feedstock`