On 04/10/2013 04:29 PM, Cole Robinson wrote: > On 04/09/2013 03:19 PM, Gene Czarcinski wrote: >> The current situation where a fixed value only is used >> for the version of the virt-manager tarball is not >> acceptable if for no other reason than it does not >> reflect just what is in the tarball. >> >> This update changes the virt-manager version id and >> introduces an *external* version id used for the sdist tarball >> and an *internal* version id which is displayed by >> ./virt-manager --version GNU coreutils has an interesting trick where it computes a version based on git, but only at 'make install' or 'make dist' time. During normal development, the version number remains unchanged (fast); but at tarball time, you choose whether you are releasing a formal version (there is a formal git tag, so the git revision is omitted from the new version string) or a development version (no formal git tag, so the version string includes the git revision), in both cases having the version string computed by gnulib's git-version-gen script. As with most autoconf projects, changing the version string in autoconf.ac then causes a full autoconf rerun to propagate the new version string everywhere it is needed. Thus, if you ever install coreutils, even if you built it from git, you have a stable version string, but for day-to-day development, you aren't burdened with the speed penalty of rerunning autoconf just to pass a new version string down. But that trick is based on using autoconf, which virt-manager does not do, so I have no idea if coreutils' trick could be easily made to play with virt-manager. > > This code also has numerous problems: > > - _check_for_git is run on every invocation of virt-manager, even a system > installed one. Agreed. If you insist on including a git version into a built product, you must install the version string (coreutils reruns autoconf with a new version string, but only when building a tarball or rpm), and NOT have the built product dynamically trying to recompute its version. Personally, I find that I don't install non-released software often enough to be bothered by whether an unreleased git build has a sane version number; on the few projects where I want bleeding edge, I can tweak things myself to alter the version number instead of trying to patch upstream to support a git revision number. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
