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

[Cole Robinson]

On 04/11/2013 12:16 PM, Gene Czarcinski wrote:
> On 04/10/2013 06:29 PM, Cole Robinson wrote:
>> Gene, I'm sorry, but I truly have no interest in maintaining this as part of
>> virt-manager. The problems you describe affect just about every open source
>> project I've worked on, so even though it_is_  sub optimal it's common enough
>> that it clearly doesn't cause too much grief, so it doesn't warrant such a
>> complex solution.
> OK, lets step back a moment.  Before, considering how something is
> implemented, I want to consider what is implemented and I have the following
> separate issues.
> 
> 1.  When python setup.py sdist is run and IF we are running under a giot-clone
> repository, then there should be a check made for outstanding/uncommited
> changes and if such changes exist, creating the tarball should be aborted.
> 
> My reasoning is that the tarball should have a "good, known base."
> 
> There is the possibility that python setup.py sdist was not run under a
> git-clone repository, the execution should proceed.
> 

If we add the MANIFEST file, I don't see why this is required really. What if
I want to create a test RPM with uncommitted changes, why should that be
disallowed? That's not a pathological example either, I've certainly done that
on several occasions when making big build system changes. Yes, I could commit
my changes first, but really, why add code to enforce it?

> 2.  Never mind what it is or how it is done, is it desirable to have some sort
> of snapshot id?  Yes, many projects have this problem, but that does not mean
> it should be ignored.
> 
> My submitted solution has many problems including that it is way
> over-engineered.  I forgot the KISS principle.  I was looking for something
> simple and the solution got a life of its own.
> 
> While it might be "nice" to capture the information returned by
> git-describe--tags, the real issue (IMHO) is to have some simple version
> differentiator for tarball and rpm names ... autobuild.sh does provide a
> differentiator for the RPMs it builds.
> 
> RPM maintainers also do their own differentiation when they build an updated
> version of some program which is not based on an official release but instead
> a point-in-time snapshot of a git repository.
> 
> So, back to the basic question: is a snapshot file-name differentiator
> something desirable?

I understand why having an RPM and tarball with a git commit/tag derived
version is useful for certain usecases. But I don't think it's sufficiently
useful that we should do it by default or complicate the build system to do so.

I think this can be solved by adding an option to sdist or rpm subcommands
that allows temporarily overwriting __version__. Then all the __version__
building logic can be moved to an external script, which just passes the value
to setup.py

- Cole