we could package the libvirt files as a proper debian package. what about moving the libvirt folder to packageswhonixlibvirt the package not the installation instructions on kvm wiki page would could files to usrsharewhonixlibvirtxmlwhonixgatewaykvm.xml and so forth.from user&39s perspective nothing would change compared to now. that package wouldn&39t be very useful for users. as long as there is no whonix host operating system httpsphabricator.whonix.orgt21 and perhaps neveradvantages we could add a unit test file usrsharewhonixlibvirtunittest that would import and remove the vm&39s to see if the xml&39s 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 httpswww.whonix.orgwikidevcontinuousintegration. travis ci most likely. it&39s ubuntu based, but that is still somewhat comparable to debian. it would detect things such as missing quotes. then we&39d 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&39t have version numbers. we could indicate, that the version number of the xml has been increased by using debianchangelog make debchlbumpup. 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 debianchangelog&39s 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 thinkone thing. whonixlibvirt might not be the best name for the package for trademark reasons httpswww.whonix.orgwikidevtpotrademark. 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&39t limit it to kvm because there is also qemu, in future perhaps more
