Where and how do we specify version dependencies?

There has been some dicussion going around the versionlock file for a while now, so let's settle this.

First of, we cannot get rid of it, in the sense that we need this version information somewhere. The question is where and how. What we currently have is not ideal. At the moment we have version information in:

• cta.spec.in
• continuousintegration/docker/ctafrontend/alma9/etc/yum/pluginconf.d/versionlock.list

The problem is that if we update 1, we most likely have to update the other as well. Defining this in two places is a recipe for disaster, so let's settle on a single place to do this.

The best way would probably be to have a central json file containing all of this information. This can be easily parsed by CMake for the cta.spec.in file and also by the cta-versionlock script that currently consumes the versionlock.list file.

Below is just a quick example of how we could do this. Using a structure makes it flexible for the future as well. Perhaps there are some things here and there hardcoded in the cmake files that would benefit from being moved to here.

{
  "name": "CTA",
  "description": "The CERN Tape Archive (CTA) is the archival storage system for the custodial copy of all physics data at CERN.",
  "license": "GNU GPLv3",
  "dependencies": {
    "eos-archive": "5.2.24-1.el9",
    "eos-cleanup": "5.2.24-1.el9",
    "eos-client": "5.2.24-1.el9",
    "eos-fuse": "5.2.24-1.el9",
    "eos-fuse-core": "5.2.24-1.el9",
    "eos-fuse-sysv": "5.2.24-1.el9",
    "eos-fusex": "5.2.24-1.el9",
    "eos-fusex-core": "5.2.24-1.el9",
    "eos-fusex-selinux": "5.2.24-1.el9",
    "eos-ns-inspect": "5.2.24-1.el9",
    "eos-server": "5.2.24-1.el9",
    "eos-srm": "5.2.24-1.el9",
    "eos-test": "5.2.24-1.el9",
    "eos-testkeytab": "5.2.24-1.el9",
    "eos-quarkdb": "5.2.24-1.el9",
    "eos-folly": "2019.11.11.00-1.el9",
    "eos-folly-deps": "2019.11.11.00-1.el9",
    "python3-xrootd": "1:5.6.1-1.el9",
    "xrootd": "1:5.6.1-1.el9",
    "xrootd-client": "1:5.6.1-1.el9",
    "xrootd-client-devel": "1:5.6.1-1.el9",
    "xrootd-client-libs": "1:5.6.1-1.el9",
    "xrootd-debuginfo": "1:5.6.1-1.el9",
    "xrootd-devel": "1:5.6.1-1.el9",
    "xrootd-doc": "1:5.6.1-1.el9",
    "xrootd-fuse": "1:5.6.1-1.el9",
    "xrootd-libs": "1:5.6.1-1.el9",
    "xrootd-private-devel": "1:5.6.1-1.el9",
    "xrootd-selinux": "1:5.6.1-1.el9",
    "xrootd-server": "1:5.6.1-1.el9",
    "xrootd-server-devel": "1:5.6.1-1.el9",
    "xrootd-server-libs": "1:5.6.1-1.el9",
    "xrootd-tests": "1:5.6.1-1.el9"
  }
}

Of course alternative solutions are also welcome