Proposal for RHEL8 missing -devel packages

[Troy Dawson]

Our current solution for the missing RHEL8 devel packages is going away.
And let's be honest, it was only about 50% successful.  We needed
something else anyway.

Here is my proposal for a new solution.
Be warned, this proposal has words like module, and grobisplitter.
But I think it will turn out good in the end.
It's just a proposal.  Some things might be impossible, some might
just be hard.  But, in my head it works.

Example: qgpgme-devel is missing.  It is a subpackage of gpgme
1 - Create a epel8 module called qgpgme-devel(A)
1a - Everything is blocked by the module, except the package qgpgme-devel
2 - In the fedora dist-git repo for gpgme, create a branch called
epel8-missing-devel(B)
2a - If other packages are needed to build gpgme in EPEL8, create the
same named branch in their dist-git repos.
3 - Sync the centos-git branches to the fedora epel8-missing-devel
branches, including sources to the fedora lookaside. (C)
4 - Change %{dist} in the spec files to .el8
5 - Build the module
6 - Process the module through the usual bodhi process, and thus EPEL
end users can use qgpgme-devel, as an EPEL module.
7 - Configure grobisplitter so that the contents of the module (which
is just qgpgme-devel) can be squashed and used as a normal rpm in
epel8 buildroot.
8 - Via a script, check centos-git branch of gpgme to see if it has
been updated.  If it has been updated, do steps 3 through 6.

Notes:
(A) - Do not name the module the same as the original source package.
This will confuse users of the original package.
(B) - This branch name is debatable, but it should be consistent so
updates can be scripted.
(C) - Once the centos and fedora dist-git branches are on the same
place, this will be easier, but is still needed.
(D) - Yes, that's right.  Hard code %{dist}

Troy

[Miro Hrončok]

On 12/11/20 7:42 PM, Troy Dawson wrote:
> Our current solution for the missing RHEL8 devel packages is going away.
> And let's be honest, it was only about 50% successful.  We needed
> something else anyway.
>
> Here is my proposal for a new solution.
> Be warned, this proposal has words like module, and grobisplitter.
> But I think it will turn out good in the end.
> It's just a proposal.  Some things might be impossible, some might
> just be hard.  But, in my head it works.
>
> Example: qgpgme-devel is missing.  It is a subpackage of gpgme
> 1 - Create a epel8 module called qgpgme-devel(A)
> 1a - Everything is blocked by the module, except the package qgpgme-devel
> 2 - In the fedora dist-git repo for gpgme, create a branch called
> epel8-missing-devel(B)
> 2a - If other packages are needed to build gpgme in EPEL8, create the
> same named branch in their dist-git repos.
> 3 - Sync the centos-git branches to the fedora epel8-missing-devel
> branches, including sources to the fedora lookaside. (C)
> 4 - Change %{dist} in the spec files to .el8
> 5 - Build the module
> 6 - Process the module through the usual bodhi process, and thus EPEL
> end users can use qgpgme-devel, as an EPEL module.
> 7 - Configure grobisplitter so that the contents of the module (which
> is just qgpgme-devel) can be squashed and used as a normal rpm in
> epel8 buildroot.
> 8 - Via a script, check centos-git branch of gpgme to see if it has
> been updated.  If it has been updated, do steps 3 through 6.
>
> Notes:
> (A) - Do not name the module the same as the original source package.
> This will confuse users of the original package.
> (B) - This branch name is debatable, but it should be consistent so
> updates can be scripted.
> (C) - Once the centos and fedora dist-git branches are on the same
> place, this will be easier, but is still needed.
> (D) - Yes, that's right.  Hard code %{dist}

At the end a package called qgpgme-devel will be built in EPEL and available in 
the EPEL buildroot despite the fact that there is a qgpgme-devel package in RHEL 
buildroot.

Since the only reason we don't allow this already is policy, why don't we amend 
the policy instead to allow adding qgpgme-devel to EPEL if it's in RHEL 
buildroot? No modules, no grobisplitter, just plain simple spec file that only 
produces qgpgme-devel (and deletes or %excludes the rest). IMHO that's something 
EPEL packagers are more likely to understand (and hence are more OK to maintain).

[Troy Dawson]

On Fri, Dec 11, 2020 at 1:44 PM Miro Hrončok  wrote:
> On 12/11/20 7:42 PM, Troy Dawson wrote:
> > Our current solution for the missing RHEL8 devel packages is going away.
> > And let's be honest, it was only about 50% successful.  We needed
> > something else anyway.
> >
> > Here is my proposal for a new solution.
> > Be warned, this proposal has words like module, and grobisplitter.
> > But I think it will turn out good in the end.
> > It's just a proposal.  Some things might be impossible, some might
> > just be hard.  But, in my head it works.
> >
> > Example: qgpgme-devel is missing.  It is a subpackage of gpgme
> > 1 - Create a epel8 module called qgpgme-devel(A)
> > 1a - Everything is blocked by the module, except the package qgpgme-devel
> > 2 - In the fedora dist-git repo for gpgme, create a branch called
> > epel8-missing-devel(B)
> > 2a - If other packages are needed to build gpgme in EPEL8, create the
> > same named branch in their dist-git repos.
> > 3 - Sync the centos-git branches to the fedora epel8-missing-devel
> > branches, including sources to the fedora lookaside. (C)
> > 4 - Change %{dist} in the spec files to .el8
> > 5 - Build the module
> > 6 - Process the module through the usual bodhi process, and thus EPEL
> > end users can use qgpgme-devel, as an EPEL module.
> > 7 - Configure grobisplitter so that the contents of the module (which
> > is just qgpgme-devel) can be squashed and used as a normal rpm in
> > epel8 buildroot.
> > 8 - Via a script, check centos-git branch of gpgme to see if it has
> > been updated.  If it has been updated, do steps 3 through 6.
> >
> > Notes:
> > (A) - Do not name the module the same as the original source package.
> > This will confuse users of the original package.
> > (B) - This branch name is debatable, but it should be consistent so
> > updates can be scripted.
> > (C) - Once the centos and fedora dist-git branches are on the same
> > place, this will be easier, but is still needed.
> > (D) - Yes, that's right.  Hard code %{dist}
>
> At the end a package called qgpgme-devel will be built in EPEL and available in
> the EPEL buildroot despite the fact that there is a qgpgme-devel package in RHEL
> buildroot.
>
> Since the only reason we don't allow this already is policy, why don't we amend
> the policy instead to allow adding qgpgme-devel to EPEL if it's in RHEL
> buildroot? No modules, no grobisplitter, just plain simple spec file that only
> produces qgpgme-devel (and deletes or %excludes the rest). IMHO that's something
> EPEL packagers are more likely to understand (and hence are more OK to maintain).

They already can if they want.
There is no policy preventing creating a srpm with a different name
that creates a binary that isn't in the RHEL release.
If fact, just the opposite, there is a special provision for that in
the packaging review guidelines
   https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
see bullet 3.

I believe what most people are worried about is keeping it in sync
with the RHEL release.
There is also a problem if a missing package has been specifically
blocked by a module.  I think libuv-devel is this way.

We discussed this in the EPEL Steering Committee this week, and your
way has alot less "mess with the server and modules" work.
It would probably get us up to 75% of the missing packages.

If people who have been waiting for packages want to give this a try
and show what they did for others to follow, that would be great.
I'll probrubly do it for some of the packages I want.  And see what
type of scripts, patches, and other things are needed.

Thanks for the feedback.  It was very helpful.
Troy

[Miro Hrončok]

On 12/12/20 12:12 AM, Troy Dawson wrote:
> > At the end a package called qgpgme-devel will be built in EPEL and available in
> > the EPEL buildroot despite the fact that there is a qgpgme-devel package in RHEL
> > buildroot.
> >
> > Since the only reason we don't allow this already is policy, why don't we amend
> > the policy instead to allow adding qgpgme-devel to EPEL if it's in RHEL
> > buildroot? No modules, no grobisplitter, just plain simple spec file that only
> > produces qgpgme-devel (and deletes or %excludes the rest). IMHO that's something
> > EPEL packagers are more likely to understand (and hence are more OK to maintain).
>
> They already can if they want.
> There is no policy preventing creating a srpm with a different name
> that creates a binary that isn't in the RHEL release.

I understood the policy here:

https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy

...as "thou shalt not package in EPEL what's already in RHEL" and 
codeready-builder-for-rhel-8 seems to "be in RHEL". If the problems are only 
with packages that are not even in CRB, but filtered out by modular "features", 
possibly such packages are indeed not disallowed (not sure, maybe the policy 
could explicitly say that they are allowed?).
> If fact, just the opposite, there is a special provision for that in
> the packaging review guidelines
>     https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
> see bullet 3.

Oh, my confusion apparently lies in "does not exist (or is not shipped) in RHEL" 
-- do I now understand this correctly that if a subpackage (e.g. qgpgme-devel) 
exists in RHEL but is not shipped, it is explicitly allowed to package it in 
EPEL under a new component name (e.g. qgpgme-devel) (and as a bonus, does not 
even need a package review)? If so, should we document this also in the EPEL policy?
> I believe what most people are worried about is keeping it in sync
> with the RHEL release.

In what way does the modularity solution make this easier? The -devel subpackage 
tagged into the epel8 buildroot needs to be in sync with the runtime package 
from RHEL in either case, doesn't it?

As for the fragility of this: I maintain an EPEL 7 package that needs to be kept 
in sync with RHEL 7 (python3-rpm) and A) RHEL doesn't release that often, B) 
when it goes out of sync, things break and I notice, so I can fix it. (Obviously 
in EPEL Next, this will be more challenging because (A) is no longer true.)
> There is also a problem if a missing package has been specifically
> blocked by a module.  I think libuv-devel is this way.

If that happens, wouldn't it be blocked in both scenarios 
(module+grobisplitter+tagging and devel-only-component)? Or would grobisplitter 
put them in an additional repo with module_hotfixes=yes?

If that's the case, it might be possible to create a separate repo with such 
packages only and manually tag them there. E.g. after a build I'd do `koji tag 
epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and the 
epel8-buildroot-module-hotfixes repo would be available from EPEL 8 Koji/mock 
builds with module_hotfixes=yes. Yes, unlike the rest of this proposal, it 
requires some work (on infra to set up this extra repo and on packagers to 
remember to do the tagging, but that still sounds like less work than the 
grobisplitter proposal for both groups).
> We discussed this in the EPEL Steering Committee this week, and your
> way has alot less "mess with the server and modules" work.
> It would probably get us up to 75% of the missing packages.
>
> If people who have been waiting for packages want to give this a try
> and show what they did for others to follow, that would be great.
> I'll probrubly do it for some of the packages I want.  And see what
> type of scripts, patches, and other things are needed.

Let me know if you have a devel package in mind and I can give it a try.
> Thanks for the feedback.  It was very helpful.

Thanks for trying to solve this problem.

[Orion Poplawski]

On 12/11/20 5:04 PM, Miro Hrončok wrote:
> On 12/12/20 12:12 AM, Troy Dawson wrote:
> > There is also a problem if a missing package has been specifically
> > blocked by a module.  I think libuv-devel is this way.
>
> If that happens, wouldn't it be blocked in both scenarios 
> (module+grobisplitter+tagging and devel-only-component)? Or would 
> grobisplitter put them in an additional repo with module_hotfixes=yes?
>
> If that's the case, it might be possible to create a separate repo with 
> such packages only and manually tag them there. E.g. after a build I'd 
> do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and 
> the epel8-buildroot-module-hotfixes repo would be available from EPEL 8 
> Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this 
> proposal, it requires some work (on infra to set up this extra repo and 
> on packagers to remember to do the tagging, but that still sounds like 
> less work than the grobisplitter proposal for both groups).

Is there any easy way to tell if a package is explicitly blocked vs just 
not being present.
> > We discussed this in the EPEL Steering Committee this week, and your
> > way has alot less "mess with the server and modules" work.
> > It would probably get us up to 75% of the missing packages.
> >
> > If people who have been waiting for packages want to give this a try
> > and show what they did for others to follow, that would be great.
> > I'll probrubly do it for some of the packages I want.  And see what
> > type of scripts, patches, and other things are needed.
>
> Let me know if you have a devel package in mind and I can give it a try.

Can we just jump in and try this out?  I'd like to get qpdf-devel 
available.  If so, I guess I would do:

fedpkg request-repo --exception qpdf-devel

right?

[Stephen John Smoogen]

On Sun, 13 Dec 2020 at 12:38, Orion Poplawski  wrote:
> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > On 12/12/20 12:12 AM, Troy Dawson wrote:
> > > There is also a problem if a missing package has been specifically
> > > blocked by a module.  I think libuv-devel is this way.
> >
> > If that happens, wouldn't it be blocked in both scenarios
> > (module+grobisplitter+tagging and devel-only-component)? Or would
> > grobisplitter put them in an additional repo with module_hotfixes=yes?
> >
> > If that's the case, it might be possible to create a separate repo with
> > such packages only and manually tag them there. E.g. after a build I'd
> > do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and
> > the epel8-buildroot-module-hotfixes repo would be available from EPEL 8
> > Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this
> > proposal, it requires some work (on infra to set up this extra repo and
> > on packagers to remember to do the tagging, but that still sounds like
> > less work than the grobisplitter proposal for both groups).
>
> Is there any easy way to tell if a package is explicitly blocked vs just
> not being present.

I thought there was one way by looking at the modules.yaml file and parse
through the yaml for artifacts and filter.. however when I was doing that
for the EPEL-8 bringup in 2019.. it was not always accurate.
> > > We discussed this in the EPEL Steering Committee this week, and your
> > > way has alot less "mess with the server and modules" work.
> > > It would probably get us up to 75% of the missing packages.
> > >
> > > If people who have been waiting for packages want to give this a try
> > > and show what they did for others to follow, that would be great.
> > > I'll probrubly do it for some of the packages I want.  And see what
> > > type of scripts, patches, and other things are needed.
> >
> > Let me know if you have a devel package in mind and I can give it a try.
>
> Can we just jump in and try this out?  I'd like to get qpdf-devel
> available.  If so, I guess I would do:
>
> fedpkg request-repo --exception qpdf-devel
>
> right?

I don't know so I can't answer this.
> --
> Orion Poplawski
> Manager of NWRA Technical Systems          720-772-5637
> NWRA, Boulder/CoRA Office             FAX: [phone]
> 3380 Mitchell Lane                       [e-mail]
> Boulder, CO 80301                 https://www.nwra.com/
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...

[Orion Poplawski]

On 12/13/20 10:37 AM, Orion Poplawski wrote:
> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > On 12/12/20 12:12 AM, Troy Dawson wrote:
> > > We discussed this in the EPEL Steering Committee this week, and your
> > > way has alot less "mess with the server and modules" work.
> > > It would probably get us up to 75% of the missing packages.
> > >
> > > If people who have been waiting for packages want to give this a try
> > > and show what they did for others to follow, that would be great.
> > > I'll probrubly do it for some of the packages I want.  And see what
> > > type of scripts, patches, and other things are needed.
> >
> > Let me know if you have a devel package in mind and I can give it a try.
>
> Can we just jump in and try this out?  I'd like to get qpdf-devel 
> available.

Here's what I have for a diff so far for qpdf-devel:

--- /export/home/orion/centos/qpdf/SPECS/qpdf.spec      2020-12-13 
10:39:15.439288925 -0700
+++ qpdf-devel.spec     2020-12-13 10:52:37.567863216 -0700
@@ -1,5 +1,7 @@
+%global debug_package %{nil}
+
  Summary: Command-line tools and library for transforming PDF files
-Name:    qpdf
+Name:    qpdf-devel
  Version: 7.1.1
  Release: 10%{?dist}
  # MIT: e.g. libqpdf/sha2.c
@@ -72,7 +74,7 @@
  QPDF Manual

%prep
-%setup -q
+%setup -q -n qpdf-%{version}

# fix 'complete manual location' note in man pages
  %patch0 -p1 -b .doc
@@ -99,35 +101,17 @@
  make install DESTDIR=%{buildroot}

rm -f %{buildroot}%{_libdir}/libqpdf.la
+rm -rf %{buildroot}/usr/{bin,share} %{buildroot}%{_libdir}/*.so.*

%check
  make check

-%post libs -p /sbin/ldconfig
-
-%postun libs -p /sbin/ldconfig
-
  %files
-%{_bindir}/fix-qdf
-%{_bindir}/qpdf
-%{_bindir}/zlib-flate
-%{_mandir}/man1/*
-
-%files libs
-%doc README.md TODO ChangeLog
-%license Artistic-2.0
-%{_libdir}/libqpdf*.so.*
-
-%files devel
  %doc examples/*.cc examples/*.c
  %{_includedir}/*
  %{_libdir}/libqpdf*.so
  %{_libdir}/pkgconfig/libqpdf.pc

-%files doc
-%{_pkgdocdir}
-
-
  %changelog

Seem reasonable?  I was able to install the resulting qpdf-devel fine.

[Miro Hrončok]

On 12/13/20 7:03 PM, Orion Poplawski wrote:
> On 12/13/20 10:37 AM, Orion Poplawski wrote:
> > On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > > On 12/12/20 12:12 AM, Troy Dawson wrote:
> > > > We discussed this in the EPEL Steering Committee this week, and your
> > > > way has alot less "mess with the server and modules" work.
> > > > It would probably get us up to 75% of the missing packages.
> > > >
> > > > If people who have been waiting for packages want to give this a try
> > > > and show what they did for others to follow, that would be great.
> > > > I'll probrubly do it for some of the packages I want.  And see what
> > > > type of scripts, patches, and other things are needed.
> > >
> > > Let me know if you have a devel package in mind and I can give it a try.
> >
> > Can we just jump in and try this out?  I'd like to get qpdf-devel available.
>
> Here's what I have for a diff so far for qpdf-devel:
>
> --- /export/home/orion/centos/qpdf/SPECS/qpdf.spec      2020-12-13 
> 10:39:15.439288925 -0700
> +++ qpdf-devel.spec     2020-12-13 10:52:37.567863216 -0700
> @@ -1,5 +1,7 @@
> +%global debug_package %{nil}
>
> Summary: Command-line tools and library for transforming PDF files
> -Name:    qpdf
> +Name:    qpdf-devel
>   Version: 7.1.1
>   Release: 10%{?dist}
>   # MIT: e.g. libqpdf/sha2.c
> @@ -72,7 +74,7 @@
>   QPDF Manual
>
> %prep
> -%setup -q
> +%setup -q -n qpdf-%{version}
>
> # fix 'complete manual location' note in man pages
>   %patch0 -p1 -b .doc
> @@ -99,35 +101,17 @@
>   make install DESTDIR=%{buildroot}
>
> rm -f %{buildroot}%{_libdir}/libqpdf.la
> +rm -rf %{buildroot}/usr/{bin,share} %{buildroot}%{_libdir}/*.so.*
>
> %check
>   make check
>
> -%post libs -p /sbin/ldconfig
>
> -%postun libs -p /sbin/ldconfig
>
> %files
> -%{_bindir}/fix-qdf
> -%{_bindir}/qpdf
> -%{_bindir}/zlib-flate
> -%{_mandir}/man1/*
>
> -%files libs
> -%doc README.md TODO ChangeLog
> -%license Artistic-2.0
> -%{_libdir}/libqpdf*.so.*
>
> -%files devel
>   %doc examples/*.cc examples/*.c
>   %{_includedir}/*
>   %{_libdir}/libqpdf*.so
>   %{_libdir}/pkgconfig/libqpdf.pc
>
> -%files doc
> -%{_pkgdocdir}
>
> %changelog
>
> Seem reasonable?  I was able to install the resulting qpdf-devel fine.

Don't forget to move the following metadata to the main package:

Summary: Development files for QPDF library
   Requires: qpdf-libs%{?_isa} = %{version}-%{release}

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.

[Stephen John Smoogen]

On Sun, 13 Dec 2020 at 13:17, Miro Hrončok  wrote:
> On 12/13/20 7:03 PM, Orion Poplawski wrote:
> > On 12/13/20 10:37 AM, Orion Poplawski wrote:
> > > On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > > > On 12/12/20 12:12 AM, Troy Dawson wrote:
> > Seem reasonable?  I was able to install the resulting qpdf-devel fine.
>
> Don't forget to move the following metadata to the main package:
>
> Summary: Development files for QPDF library
>    Requires: qpdf-libs%{?_isa} = %{version}-%{release}

Do you mean the main package as qpdf ? We don't control that package.
> 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.

That makes sense.
> --
> Miro Hrončok
> --
> Phone: [phone]
> IRC: mhroncok
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...

[Miro Hrončok]

On 12/13/20 7:21 PM, Stephen John Smoogen wrote:
> Don't forget to move the following metadata to the main package:
>
>     Summary: Development files for QPDF library
>     Requires: qpdf-libs%{?_isa} = %{version}-%{release}
>
>
> Do you mean the main package as qpdf ? We don't control that package.

No. I mean the main qpdf-devel package of the qpdf-devel component.

So when I've said "move" I should have said "copy" instead, sorry.

[Andrew C Aitchison]

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 ?

[Miro Hrončok]

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?

[Andrew C Aitchison]

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.

[Troy Dawson]

On Tue, Dec 15, 2020 at 5:06 AM Andrew C Aitchison
 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

[Kevin Fenzi]

On Sun, Dec 13, 2020 at 10:37:49AM -0700, Orion Poplawski wrote:
> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > On 12/12/20 12:12 AM, Troy Dawson wrote:
> > > There is also a problem if a missing package has been specifically
> > > blocked by a module.  I think libuv-devel is this way.
> >
> > If that happens, wouldn't it be blocked in both scenarios
> > (module+grobisplitter+tagging and devel-only-component)? Or would
> > grobisplitter put them in an additional repo with module_hotfixes=yes?
> >
> > If that's the case, it might be possible to create a separate repo with
> > such packages only and manually tag them there. E.g. after a build I'd
> > do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and
> > the epel8-buildroot-module-hotfixes repo would be available from EPEL 8
> > Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this
> > proposal, it requires some work (on infra to set up this extra repo and
> > on packagers to remember to do the tagging, but that still sounds like
> > less work than the grobisplitter proposal for both groups).
>
> Is there any easy way to tell if a package is explicitly blocked vs just not
> being present.

You can ask koji:

koji list-pkgs --show-blocked --package whatever

and it will tell you what tags it's blocked in with [BLOCKED]

kevin