[virt-tools-list] [PATCH-v5.5 5/5] virt-manager version-id changes

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20130410/56b1f4ec/attachment.sig>