The deprecation policy is primarily intended for notifying of changes to QEMU's stable interfaces ( CLI, HMP, QMP) which affect behaviour and usage of QEMU at runtime & are liable to break apps managing QEMU.
Changes to build time options have no strong reason to be subjected to the deprecation process.
This sounds reasonable to me. But: Should our deprecation policy be clearer on what is subject to our deprecation procedure, and what is not? Regards, Aleksandar
If we remove an option at build time the effect is noticed immediately and the solution is straightforward (stop passing the option). We have added / removed configure options at will with little negative feedback historically. We'll have far biggest changes coming to the build system in future too, with the introduction of meson.
I don't think we want to constrain & complicate our work in modernizing the build system by declaring that any changes to it must go through deprecation.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|