On Tue, 2021-04-20 at 15:20 +0200, Pavel Hrdina wrote: > On Tue, Apr 20, 2021 at 02:14:59PM +0100, Daniel P. Berrangé wrote: > > On Tue, Apr 20, 2021 at 03:05:26PM +0200, Andrea Bolognani wrote: > > > The only concern I have, which is one I have expressed already in the > > > past, is that it will now be harder for users and packagers alike to > > > figure out that they don't have a certain optional program installed: > > > AFAICT, after your patches the only way would be to try using each > > > feature and look out for errors. > > > > I'd say that running "meson" and looking at its output is a poor > > way for users to learn what the pre-requisites are, both before > > and after this change. > > > > Ideally we should document the list of packages we depend on. > > We have it sorta documented in the many docker files. > > > > I wonder if we should include the list of mapping names from > > libvirt-ci as an explicit doc item in README.md or somewhere > > else that could be useful. Or just tell tem to look at the > > dockerfiles. Even if their distro isn't covered, it'll be > > enough info for them to get most of the way there. > > Agreed, instead of having it in meson I would also prefer having it > documented somewhere. Ideally we should not document only what optional > programs we use but every single dependency we use ideally with links to > upstream projects and possibly examples of downstream packages which is > as Dan pointed out stored in libvirt-ci. Documentation is great and all, but the problem with it is that it's extremely easy for it to become outdated as new optional runtime dependencies are added; the advantage of having this list stored in Meson is that the person who's adding a new optional runtime dependency is likely to look around for how the existing ones are handled, and thus automatically do the right thing. The point about libvirt-ci storing all the dependencies is a good one, but note that we only keep track of *build time* dependencies for projects: that is, once e.g. dnsmasq is no longer required to be available in the build environment in order to produce a fully-featured libvirt build, we'll simply stop including it. This will happen with almost all other optional runtime dependencies too, so really the mappings that are maintained as part of the libvirt-ci project doesn't solve the issue of keeping track of optional runtime dependencies at all. -- Andrea Bolognani / Red Hat / Virtualization
