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/#_package_review_process
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
