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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
