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.
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
