On 12/17/2015 04:13 PM, Franck Bui wrote:
> Hi Andreas,
> 
> On 12/17/2015 03:23 PM, Andreas Färber wrote:
>> Hi Franck,
>>
>> Am 17.12.2015 um 15:05 schrieb Franck Bui:
>>> On 12/16/2015 07:34 PM, Marcus Meissner wrote:
>>>> On Wed, Dec 16, 2015 at 07:01:45PM +0100, Andreas Färber wrote:
>>>>> Today's https://build.opensuse.org/request/show/347433 seems to have
>>>>> broken 13.2 builds of Virtualization qemu.
>>>>>
>>>>> We have the following snippet there:
>>>>>
>>>>> %if %( echo `rpm -q --queryformat %%{version} udev` ) > 190
>>>>> %define _udevrulesdir /usr/lib/udev/rules.d
>>>>> %else
>>>>> %define _udevrulesdir /lib/udev/rules.d
>>>>> %endif
>>>>>
>>>
>>> can't you use '%_udevrulesdir' macro instead ?
>>
>> Does that work as far back as 13.1 or SLE11? That snippet is obviously
>> not my invention, so you tell me.
>>
> 
> I would say: if it's defined then use it otherwise define it as
> '/lib/udev/rules.d': on distribution where it's defined, systemd is used
> and udev is >= 210 in this case. Otherwise sysvinit is still used and
> udev is old enough to look for its rules files in /lib/udev.
> 
> That said it might make sense to introduce %_udevrulesdir in udev
> package for SLE11 (and any other supported products using udev).
> 
>>>>> From systemd.3661 to systemd.4042 I notice the following change:
>>>>> -Version:        210
>>>>> +Version:        210.1448627060.53ee915
>>>>> which looks _service-generated. Was this intentional? If yes, how are we
>>>>> supposed to handle this now?
>>>
>>> Well, I don't know but I would have expected this solved at the time the
>>> _service thing had been introduced.
>>
>> Well, for me, this was introduced yesterday. ;)
> 
> only a couple of weeks to me ;)
> 
>> We do not see any problems with Factory so far, is there a similar
>> submission in flight?
>>
> 
> not yet, factory is still getting the source code from a tarball (not
> from the git repo).
> 
>> Might it be an option to simply drop the automatic set_version service
>> and bumping it manually? (I recently played with it for
>> hardware/libjaylink and did not find a way to fully customize it beyond
>> %ct for the second component.)
> 
> Well set_version avoids any human intervention so it's less subject to
> mistake. And since it's there, it's supposed to be used and fixed if broken.
> 
> BTW which error are you seeing ?
> 

You probably got:

error: parse error in expression
error: /home/foo/rpmbuild/SPECS/test.spec:25: bad %if condition

$ cat test.spec
Version:        210.1448627060.53ee915
[...]
%pre
%if %{version} > 190
echo version comparaison works
%endif
[...]

Actually doing:

  %if 210.1 > 190
  %if 210rc1 > 190

lead to a parse error as well. It seems that only numerical operands can
be used in a %if conditional expression, version operands seems to be
not supported.

It would be nice if someone could clarify the syntax, I can't find any
relevant rpm specification/documentation.

Thanks.


-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to