Release publication and xDAQ version
Summary
As discussed during today's meeting, explicitly linking against xDAQ libraries without relying on the custom dependency check raise a concern about software compatibility. No compatability check based on the SONAME version can be performed (the xDAQ libraries are built without SONAME). Moreover, the xDAQ library ABI and API changed in the past without version package update.
Apart for simpler GEM software deployment, explicitly linking against the xDAQ libraries is required to build and run unit test binaries. The possibility of automated test, and considering the sub-optimal dependency system, overpasses the drawbacks of not using the custom run-time dependency checks.
However, the absence of SONAME makes difficult for someone to guarantee that the cmsgemos
software built on one host will work on a different host. More than that, the xDAQ release is not part of the RPM package version. As explained by @sturdy, the xDAQ group provides different Yum repositories for each release. Therefore, it is rather easy to chose and stick to a xDAQ version on both the build and target machine. Each cmsgemos
release would be build against a specific xDAQ version and updates would be made when required/desired.
On the other hand, a naive implementation requires manual intervention from the setup sysadmin in order to update the xDAQ repositories to the correct version. It does not seem that a single repository provides all the releases (that should be the norm with CentOS 8 where the official "update" repositories were removed).
Considering those facts, what would be the xDAQ deployment system/ update procedure? The burden of updating the repositories, particularly on the remote test stands, should be minimized as much as possible.
What is the expected correct behavior?
A defined procedure about the xDAQ releases and updates should be defined and documented. System administration tasks should be minimized as much as possible.