[libvirt] [libvirt-jenkins-ci PATCH 05/18] ansible: Add libvirt-cim project

[Andrea Bolognani]

On Tue, 2017-10-03 at 10:02 +0100, Daniel P. Berrange wrote:
> In the very last patch you add a bunch of files which define aliases for
> the various dependancies, and map those to the distro specific package
> name eg
> 
> +cyrus-sasl:
> +  - cyrus-sasl       # FreeBSD
> +  - cyrus-sasl-devel # CentOS, Fedora
> +  - libsasl2-dev     # Debian, Ubuntu
> 
> Given these data maps, it seems like we ought to be able to define the
> build pre-requisites once in terms of the alias names, and then expand
> that into the distro specific package lists, thus avoiding a per-distro
> list of deps for each module

It's a little more complicated than that, though.

Some dependencies have different names based not just on the OS
but also on the specific version, eg.

  gnutls:
    - gnutls          # FreeBSD
    - gnutls-devel    # CentOS, Fedora
    - libgnutls-dev   # Ubuntu <= 14
    - libgnutls28-dev # Debian, Ubuntu 16

Other dependencies might only be availabe on a subset of the OSs
we support, eg.

  libblkid:
    - libblkid-dev   # Debian, Ubuntu
    - libblkid-devel # CentOS, Fedora

I get the argument against redundancy, but in this case I feel like
the current representation is possibly preferable to a more compact,
less redundant one because it's *way simpler*, both in terms of the
variable files themselves and the Ansible code required to use them.

Would having something like

  gnutls:
    CentOS:
      6: gnutls-devel
      7: gnutls-devel
    Debian:
      8: libgnutls28-dev
      9: libgnutls28-dev
    Fedora:
      25: gnutls-devel
      26: gnutls-devel
      Rawhide: gnutls-devel
    FreeBSD:
      11: gnutls
    Ubuntu:
      12: libgnutls-dev
      14: libgnutls-dev
      16: libgnutls28-dev

or

  gnutls:
    gnutls:
      - FreeBSD-11
    gnutls-devel:
      - CentOS-6
      - CentOS-7
      - Fedora-25
      - Fedora-26
      - Fedora-Rawhide
    libgnutls-dev:
      - Ubuntu-12
      - Ubuntu-14
    libgnutls28-dev:
      - Debian-8
      - Debian-9
      - Ubuntu-16

plus Ansible machinery to expand it really be better than what I'm
proposing? I guess we could have a more compact representation, but
that would be at the cost of even more complex Ansible machinery.
The above is still somewhat redundant, and IMHO less usable because
not only the redundancy is staring right at you instead of being
confined to separate files, you also just introduced one extra layer
of indirection.

What if one of the build dependencies is too old to be used by
libvirt but libosinfo can use it just fine? How would you describe
something like that in a machine-readable way without making the
whole thing utterly unusable by humans?

-- 
Andrea Bolognani / Red Hat / Virtualization