On Fri, Dec 11, 2020 at 1:44 PM Miro HronĨok <mhroncok(a)redhat.com> 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/ReviewGuideline...
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