mirror of
https://gitlab.com/virt-viewer/virt-viewer.git
synced 2025-01-06 13:17:45 +03:00
The virtual machine console viewer application code
668c52775f
It turned out that not only the current MSI broke the "component rule", but also that our files are not versionized correctly. Windows Installer applies some file versioning rules before replacing a file http://msdn.microsoft.com/en-us/library/aa368599%28v=vs.85%29.aspx Since msitools doesn't extract version from files and populate the Version field of the File table, it "usually" keep the current file installed. It's practically impossible to rely on version information from files (from a quick look, only 5% of the files are versionized and even less correctly, libgcrypt seems to do non-monotonic buildid for example) So the rule that applies when files are not versionized is to check the file hash, and the modified date. File hash was added recently in msitools, but doesn't apply when the installed file itself has a version. In order to solve the above problems, it's simpler to just have a different installation prefix. Windows Installer will see files with different component guid, and won't be checking any file update rule. I have verified the upgrade is working, not leaving any file behind and updating registry correctly with this solution. Until the files are correctly versionized, it looks like the only sensible thing to do. Furthermore, this make it simpler to have several versions installed in parallel later on (when we change productid) |
||
---|---|---|
.tx | ||
build-aux | ||
data | ||
icons | ||
m4 | ||
man | ||
po | ||
src | ||
.mailmap | ||
acinclude.m4 | ||
AUTHORS.in | ||
autobuild.sh | ||
autogen.sh | ||
cfg.mk | ||
ChangeLog | ||
configure.ac | ||
COPYING | ||
git.mk | ||
GNUmakefile | ||
intltool-extract.in | ||
intltool-merge.in | ||
intltool-update.in | ||
maint.mk | ||
Makefile.am | ||
mingw-virt-viewer.spec.in | ||
NEWS | ||
README | ||
virt-viewer.spec.in |
Virt Viewer =========== Virt Viewer provides a graphical viewer for the guest OS display. At this time is supports guest OS using the VNC or SPICE protocols. Further protocols may be supported in the future as user demand dicatates. The viewer can connect directly to both local and remotely hosted guest OS, optionally using SSL/TLS encryption. Virt Viewer can be built with either GTK2 or GTK3, with the default option currently being GTK2. The choice can be made with: ./configure --with-gtk=3.0 (or =2.0) Virt Viewer uses the GTK-VNC (>= 0.4.3) widget to provide a display of the VNC protocol, which is available from http://gtk-vnc.sourceforge.net/ Virt Viewer uses the SPICE-GTK (>= 0.22) widget to provide a display of the SPICE protocol, which is available from: http://spice-space.org/page/Spice-Gtk Use of either SPICE-GTK or GTK-VNC can be disabled at time of configure, with --without-gtk-vnc or --without-spice-gtk respectively. Virt Viewer uses libvirt to lookup information about the guest OS display. This is available from http://libvirt.org/ Further information about the Virt Viewer application can be found on the Virt Manager website: http://virt-manager.org/ Feedback should be directed to the mailing list at http://virt-manager.org/mailinglist.html -- End