ADIOS2
ADIOS2 copied to clipboard
Debian Package
Hi @KyleFromKitware,
just checking in: can you tell me the status of the Debian package support for ADIOS2, please? This would be great for many of my integrations in our downstream software stack.
Cheers, Axel
Hi @ax3l,
The dh-cmake
helper package was accepted into Debian unstable several months ago. Around that time, I filed RFS (requests for sponsorship) for ADIOS and its various dependencies, but did not get any responses. If there is still demand and funding for this, I will reach out to Alastair, the sponsor for dh-cmake
, and ask if he'd be willing to sponsor ADIOS and friends, or find someone who is. (This would happen around the beginning of January, as I am about to take a vacation.)
Hi @KyleFromKitware,
thank you for the update, this sounds like great progress. @pnorbert @sklasky, do you think this effort could be finalized?
@KyleFromKitware it looks like a dependency, libevpath-dev, is not yet building. If this is time consuming, I would be fine to skip EVPATH for a first ADIOS2 Debian package and add support later, mainly because I am not using it and this can be fixed after onboarding: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960462
Hi All, just asking on the status of @KyleFromKitware work (thanks @KyleFromKitware, nice job!). Should we plan for our own repo and perhaps, expand also to rpms (I have some RHEL use cases)? The barrier of entry is pretty high without an active sponsor for debian or fedora's epel (unlike conda, spack, brew).
@pnorbert do you think there is a chance to push this again? Debian inclusion of ADIOS2 would be great and trickle down to Ubuntu et al.
@ax3l should we try snap (or maybe not)? This is the debian repo in question.
X-ref development branch: https://packages.debian.org/bullseye/dh-cmake
X-ref Debian discussion and Debian maintainer support: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960339
Upstreamed dh-cmake
is done:
https://packages.debian.org/bullseye/dh-cmake
https://www.kitware.com//rethinking-debian-packaging-for-vtk-and-other-cmake-projects-part-1/
My suggestion is to start with a lowered number of dependencies, e.g., w/o SST and EVPATH, and then work our way up.
cc @vicentebolea
@scottwittenburg