We could package the libvirt files as a proper Debian package. What about moving the libvirt folder to packages/whonix-libvirt? The package (not the installation instructions on KVM wiki page) would could files to /usr/share/whonix-libvirt/xml/Whonix-Gateway_kvm.xml and so forth.
From user's perspective nothing would change compared to now. (!)
That package wouldn't be very useful for users. [As long as there is no Whonix Host Operating System (https://phabricator.whonix.org/T21) and perhaps never?]
- We could add a unit test file /usr/share/whonix-libvirt/unit_test that would import and remove the VM's to see if the xml's are working as expected. Eventually it would also use the xml validation tool.
- That unit test could be automatically run after each and every commit using CI (https://www.whonix.org/wiki/Dev/Continuous_Integration). Travis CI most likely. It's Ubuntu based, but that is still somewhat comparable to Debian. It would detect things such as missing quotes.
- Then we'd have some more confirmation, that the xml files are Debian compatible.
- Getting the libvirt folder out of the main source code folder.
- Would make it easier to add a version number to the xml files. Since at the moment, they don't have version numbers. We could indicate, that the version number of the xml has been increased by using debian/changelog /
make deb-chl-bumpup. We could have a unit test, that runs during the build process and breaks it when the version numbers of the xml files do not match debian/changelog's version number.
- Maybe some users would notice when that package gets updated, that libvirt files are now available in a higher version number.
What do you think?
One thing. whonix-libvirt might not be the best name for the package for trademark reasons (https://www.whonix.org/wiki/Dev/TPO_Trademark). Some are rather picky about it and I like to be one the very safe side to not have to rename it later. You know any good package name that does not include "libvirt" but at the same time doesn't limit it to kvm [because there is also qemu, in future perhaps more]?