[Ovirt-devel] [PATCH *ALL*] Makefile.am: set OVIRT_DEV from Release: 0 in spec.in file

Jim Meyering jim at meyering.net
Thu Oct 9 15:44:51 UTC 2008


"Perry N. Myers" <pmyers at redhat.com> wrote:
> Jim Meyering wrote:
>> I'd been running "make build" without setting OVIRT_DEV.
>> That would cause trouble due to using out of date RPMs.
>> But in development, we should always simply set OVIRT_DEV=1.
>> We know we're in development mode when the spec.in file contains
>> has a line that starts like this:
>>
>>     Release: 0
>>
>> so I've adjusted all Makefile.am files to automatically do
>> what we want.  Painful to have to put this same snippet in
>> 7 different repositories, but very soon I'll be motivated
>> (and have time) to factor out the worst of that duplication.
>
> These patches seem to work fine, and I would ACK them except...
>
> I've noticed that occasionally the rpm flags for OVIRT_DEV are not set
> properly in the ovirt-appliance repo, causing the version for
> ovirt-appliance to occasionally be 0.94-0 even though the Release is 0
> in the spec file.  I can't seem to replicate the error with any
> consistency. It just happens once and a while with seemingly the same
> environment (I know there must be something different, but haven't
> pinned it down yet)
>
> If anyone has seen this behavior w/o these patches applied please let
> me know, as maybe this has been a problem all along.  It could be that
> the bashism used to set rpm_flags is not working properly in the
> Makefile.

Hi Perry,

I've run "make build" several times, both with and without OVIRT_DEV=1
in my environment, (though just for the first few seconds each time,
which is enough to see the relevant rpmbuild command),
and every time I saw the expected .git... argument:

   --define "extra_release .$(date --utc +%Y%m%d%H%M%S)git$(git log -1 --pretty=format:%h)"

Ah ha.
But if I build with "make publish OVIRT_DEV=",
*then* I see what you report: no extra_release definition.

To reduce the likelihood of that happening,
I could change the variable name to e.g., _OVIRT_DEV.
But maybe it's not worth worrying about.
You choose.




More information about the ovirt-devel mailing list