The configure mechanism is lenient in its requirements consistent with it trying to do the best it can for new users of ./configure;make;make install
The binary builds for specific platforms, on the other hand, are not lenient. Everything possible on a fully loaded instance of the platform should be built, and hard errors should occur if something changes or goes missing.
The strictness override is provided from the spec file (for rpm systems) and the rules file (for deb systems) In both of those mechanisms you will find ./configure args that hard --enable or --disable various features.
I do think I/we have a problem with dealing with variations between distros eg. Ubuntu 16 v 18, and Centos 6 v 8.
At the moment the Redhat version of this is dealt by lots of conditionals in the spec file. This works but is messy. It was done this way so that a single spec file, and a single graphviz.src.rpm, work on all redhat platforms. I no longer consider this important, and in fact we ship separate src.rpm for each distro even though they are internally identical and portable.
I don’t know how to implement similar conditionals in the debian rules file.
I’m starting to think about separate spec files, and rules files, for each distro.
I’m thinking the correct file would be selected from a set of alternates by the .gitlab-ci.yml at the beginning of pipeline stage 2.
Just thinking out loud…