On Tue, Dec 15, 2020 at 5:06 AM Andrew C Aitchison
<andrew(a)aitchison.me.uk> wrote:
On Tue, 15 Dec 2020, Miro Hrončok wrote:
> On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
>>
>> On Sun, 13 Dec 2020, Miro Hrončok wrote:
>>
>>> Also, since you might want to bump the release independently in EPEL (e.g.
>>> if we discover something was wrong in the way we have packaged this), I
>>> recommend doing:
>>>
>>> %global rhelrelease 10
>>> %global baserelease 1
>>> Release: %{rhelrelease}.%{baserelease}%{?dist}
>>> ...
>>> Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
>>>
>>> (Assuming qpdf has regular %{dist} and not some modularity artificial
>>> value.)
>>>
>>> Note that I've named the EPEL part of the release
"baserelease", so
>>> rpmdev-bumpspec does the right thing.
>>
>> If rhelrelease updates to 10.1 which will win ?
>> ... and if we have already bumped baserelease to 2 ?
>>
>> rhelrelease name
>> baserelease
>> 10 2 qpdf-devel-10.2.epel.rpm
>> 10.1 qpdf-devel-10.1.rhel.rpm
>>
>> Which will win ?
>
> Right. Can we use ^ in EL8 to separate the RHEL and EPEL parts?
"^" sorts after digits (at least in ASCII and Basic Latin), so
can anyone check whether
qpdf-devel-10^2.epel.rpm
will trump
qpdf-devel-100.1.rhel.rpm
or
qpdf-devel-10.3.rhel.rpm
?
My recollection is that there have been several different
implementations of parsers for version-release checks with different
twisty paths for splitting sub-components.
My last RedHat based system is SL6 (sorry I moved to Ubuntu to match
work) so I couldn't do a reliable test myself.
Sorry I'm late in replying, but why don't you use
Release: %{rhelrelease}%{?dist}.%{baserelease}
rhelrelease baserelease name
10 2 qpdf-devel-10.el8.2.rpm
10.1 2 qpdf-devel-10.1.el8.2.rpm
$ rpmdev-vercmp 10.el8.2 10.1.el8.2
10.el8.2 < 10.1.el8.2
Troy