= phenomenon =
The Spacewalk project uses cobbler as one of its components. For quite some time we've faced issues when cobbler in EPEL got rebased to latest upstream, even before the rebase was done and verified in Fedora, while breaking all sorts of stuff, SELinux being the most prominent. This rendered Spacewalk installations often unusable.
= background analysis =
I believe that the rebase of cobbler from 2.0 to 2.2 and subsequent rebases in attempt to fix the situation break the EPEL Guidelines and Policies as outlined at
because it was done based on the "hey, there is a new version, it builds, let's ship it" attitude. Fixes for issues that were subsequently found were done via more rebases, introducing more bugs.
The bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=838898 is a typical example of the problem. The way I read it, maintainer plans to keep rebasing the package (when cobbler includes a new feature it will most likely break with SELinux enabled) while not attempting to integrate with the rest of the RHEL + EPEL distribution properly (What we DO recommend is that you disable SELinux unless you are comfortable writing policy). He furthermore recommends EPEL users to clean up the mess (how about submitting some patches to either Dan/Fedora or myself to fix the issue instead).
The net result is a situation that any user running with SELinux enforcing (which was possible with Spacewalk 1.7 and the original cobbler 2.0) finds themselves out of luck and pushed to Permissive by one package which got rebased (IMO) unnecessarily and without proper testing. Weeks of work spent by many people to achieve working enforcing setup are lost and we are at square one.
From my point of view, having important pieces of infrastructure (cobbler is a provisioning tool) without SELinux Enforcing is not acceptable.
= implementation recommendation =
I would like FESCo to become a mediator in the situation.
Either my expectation of the proper maintainership of packages in EPEL are way off and I'd like to be explained by FESCo how diminishing the SELinux support in EPEL is beneficial to our users and the project as a whole. In that case I will go ahead and package known working version of cobbler in Spacewalk project, forking the effort (sadly) but giving Spacewalk users what they don't get from EPEL.
Or cobbler maintainer's policy WRT rebases and SELinux is not matching the guidelines and intent of EPEL, and I'd like someone from FESCo to explain it better than I did in bugzilla 838898, because I clearly failed.
Historically, this shouldn't be going to FESCo. If there was an org chart for the fedora Project, epel would not historically be underneath FESCo... epel problems are handled by the governance model in epel. In the past, there was an epel steering committee that was an equivalent to FESCo. Current epel governance is much looser and seems to take more of an approach of people who are showing up to do the work making the decisions.
I think that this problem should probably be taken to the epel mailing list to be hashed out and if a decision can't be found there, the request for mediation should go to the Board (because EPEL gets its charter from the Board) or the Community Working Group if that has been reformulated by then.
Hm, I wasn't aware it's not our job to help in this case.
Adelton, could you try epel mailing list or the cwg for help?
Per today's FESCo discussion, please try to resolve this within the EPEL SIG on the epel-devel mailing list; please reopen this ticket if that fails.
Moved the question to epel-devel-list:
to comment on this ticket.