On Fri, Dec 11, 2020 at 1:44 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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/#_package_review_process
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
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
